Dynamics
|
|
Generational Dynamics |
| Forecasting America's Destiny ... and the World's | |
| HOME WEB LOG COUNTRY WIKI COMMENT FORUM DOWNLOADS ABOUT | |
How should an organization manage mixed generations? That was the subject of the talk that I gave on Thursday to the Boston Tech Professionals Group, and the subsequent discussion. The specific session was targeting IT (information technology) organizations, but many of the principles apply to any organization.
|
The problem is that now, with the disappearance of the Silent Generation (the survivors of World War II), there's no one left with any real leadership skills:
Solutions are very hard to come by.
One manager said that he had a multi-generational group, but he said that any problems had nothing to do with generations, just that there may be unethical people in any group of people.
This may be true, but it's the generational constellation that makes the unethical actions possible: The boomers are just stupid, which leads to being unethical; the Gen-Xers think that every value that Boomers and Silents hold dear is crap, which leads them to being unethical. Being unethical requires opportunity as well as motive, and it's the constellation of generations that provides the opportunity.
Another manager said that what he's seen is that the real differences are between different cultural and ethnic groups, not between generations. He said that people tend to stick with their own cultural groups, irrespective of generations.
This is a tricky problem, since there are cultural and ethnic fault lines in any society. Thus, groups may experience racial (black versus white) conflicts, ethnic (Anglo vs Latino) conflicts, or religious (Christian vs Muslim) conflicts, especially if some event triggers this kind of conflict. However, there probably still is a generational issue, having to do with one generational more willing to cross cultural lines than another. This requires more research.
The differing values, attitudes and work styles of the generations are outlined in an article, by Diane Piktialis of human resources firm Ceridian Corp. In brief, the differences are as follows:
What's interesting about the above descriptions is to contrast the non-consecutive generations.
If you compare the Silents with the Gen-Xers, you find that Silents value hard work and loyalty, while Gen-Xers value a work-life balance and an informal work environment.
If you compare Boomers with Millennials, you have to take into account that Boomers have spent their entire lives disrepecting their parents and rejecting authority. This is in contrast to Millennials, who are respectful of authority and work well with older people, although they reject the constant fighting and bickering that they see with older people.
The above descriptions don't highlight the major source of generational conflict: The narcissism and arrogance of the Boomers, contrasted with the nihilism of Gen-Xers, who see no value in Boomers or Silents and can be destructive of anything that came before.
 |
Something that Boomers and Gen-Xers share, but which was rare among Silents, is what I've been calling "lenscap stupidity" or "lenscap blindness." This refers to a February, 2007, photo showing Israeli defense minister Amir Peretz spending a half-hour military briefing looking through binoculars with the lenscap on. How stupid do you have to be to keep looking through binoculars with the lenscap on?
Looking at facts through binoculars with the lenscap on has several advantages. It lets you imagine any facts you want, and ignore any facts you don't like. That's why the 2006 war with Hizbollah was so disastrous for Israel -- what do you expect when the Defense Minister looks at the war through binoculars with the lenscap on?
And so we have the "lethal combination" that I've frequently described, because the pragmatic Gen-Xers, frustrated by the Boomers' arrogance and unwillingness to lead, end up becoming de facto leaders. But because both generations exhibit lenscap stupidity, they can lead an organization to disaster. We're already seen this in financial insitutions, and this article explores the same thing in IT organizations.
There's a growing controversy in the software development world over the quality of computer science education. Specifically, many computer science graduates know nothing about basics and fundamentals, but only know cookbook approaches to writing software using predefined templates.
The controversy is sometimes framed using the word "JavaSchools" in a pejorative sense to describe computer science majors at some colleges, as in this blog entry by Joel Spolsky of Fog Creek Software:
If I may be so brash, it has been my humble experience that there are two things traditionally taught in universities as a part of a computer science curriculum which many people just never really fully comprehend: pointers and recursion.
You used to start out in college with a course in data structures, with linked lists and hash tables and whatnot, with extensive use of pointers. Those courses were often used as weedout courses: they were so hard that anyone that couldn't handle the mental challenge of a CS degree would give up, which was a good thing...."
This view is supported by a recent article in the January, 2008, edition of The Journal of Defense Software Engineering, entitled "Computer Science Education: Where Are the Software Engineers of Tomorrow?":
These trends are visible in the latest curriculum recommendations from the Association for Computing Machinery (ACM). Curriculum 2005 does not mention mathematical prerequisites at all, and it mentions only one course in the theory of programming languages.
We have seen these developments from both sides: As faculty members at New York University for decades, we have regretted the introduction of Java as a first language of instruction for most computer science majors. We have seen how this choice has weakened the formation of our students, as reflected in their performance in systems and architecture courses. As founders of a company that specializes in Ada programming tools for mission-critical systems, we find it harder to recruit qualified applicants who have the right foundational skills. We want to advocate a more rigorous formation, in which formal methods are introduced early on, and programming languages play a central role in CS education."
These observations interact with the descriptions of generations in the workplace given above in the following ways:
Silents value hard work, and so value learning fundamentals and excellence in computer software systems. This means that as long as Silents are in charge, generally the period until the early 1990s, Boomers follow those same values.
We can reasonably assume that loss of quality in IT projects follows the same time frame as the path of the global finance bubbles. In previous articles, we've used the following graph to relate generations to the dot-com bubble, starting in 1995, and the real estate and credit bubbles, starting in 2003:
 |
If IT organizations have followed the same loss of standards and ethics that finance organizations have followed -- and we assume that they have -- then IT project quality would have begun falling around 1995, and real dumbing-down of IT would have begun around 2003.
Special mention should be made of the Y2K project. As I discussed in a previous article, Y2K was a highly successful IT project, costing hundreds of billions of dollars worldwide, that kept the computers running without error past January 1, 2000. This project was largely managed by Silents, and might be called "the last gasp of the Silent Generation."
As we discussed, the Y2K project was SO successful that Gen-X software engineers are contemptuous of it, assuming that it could not have been successful without being extremely simple.
It seems highly likely that if the Y2K project had occurred 5-10 years later (or, to put it another way, if WW II had occurred 5-10 years earlier), then Boomers and Gen-Xers would have been in charge, and the project would have been far less successful, and might have been a total disaster.
The observations about Java cookbook programming are supported by two things from my own personal experience.
|
First, I've taught computer programming courses a number of times, in various programming languages (such as PL/I in the 1970s, C in the 1980s, C++ in the 1990s, Java in the 2000s). What I found is the same thing each time.
Students can understand the basic concepts, such as assignments (x = y + 2), flow of control (if, for, while), subroutines and functions. They can understand that a variable might be fixed point (x = 2) or floating point (x = 2.78E10) or even a string (x="hello"). But when I get to pointers and data structures, I lose about 1/3 of the class, no matter what the programming language. The concepts of the value of a variable being not an integer but a pointer to an integer (p->x) or the idea of accessing an element of a structure (p->s.x) are at a level of abstraction beyond about one-third of computer programming students, in my experience.
The second observation has to do with some of the project failures that I've seen. I've had dozens of clients over the years, and I've seen it from both sides: I've participated in a few disasters, and I've been brought in as a consultant to save projects facing disaster. I've developed some pretty firm ideas about what causes project failures.
At an individual level, programmers following a cookbook may be able to create a web page or generate a report, provided that nothing goes wrong, but when something unexpected happens they're lost. Typical issues that are beyond the capabilities of many programmers are memory management problems (too much memory, memory thrashing, memory fragmentation) and logic errors (not grasping, for example, what a "loop invariant" is).
At a system level, managers constantly overlook integration issues. For example, in a telemarketing application being developed by Fidelity in the 1990s, the plan called for five components, each developed by a different programmer over three months. At the end of that time, the five components would be put together into a complete system. The problem was that the interfaces were poorly designed and the integration issues were poorly planned, and the entire project crashed and burned.
Integration problems are the most common reason why cookbook programming fails, in my experience. Managers think that you can have one person broil the steak, another person make the vegetables, and a third person make the potatoes, and put them on the table and have a meal. Well you can do that in a restaurant, but not in an IT project.
Collusion as a problem was identified by Frederick P. Brooks in his classic book The Mythical Man-Month, which describes the 1960s software development effort for OS/360, the IBM mainframe operating system.
Collusion occurs when both the programmer and the manager collude with one another to pretend a programming project is on schedule and proceeding OK. It's not unusual for this kind of collusion to continue until the day on which the product is scheduled for delivery. On that day, the project that had been on schedule for months suddenly slips six months.
I actually saw this in 1985 at Northrop, one of my first big clients. I was supervising the project, and concluded that it would slip 3-6 months. I told the program manager, and he nearly freaked out. I was pulled into a number of meetings and nearly fired. I still remember a bizarre day in the lab, about two weeks before the scheduled delivery, when the project was being demoed to a vice president. He watched the demonstration, and then asked, "And the development will be completed by a week from Monday?" I held my breath as the programmer said, "Yes," and the manager said, "Yes." The project did slip six months, and I wasn't fired, though it was very close.
Although collusion has existed all along, my observation is that the nature of collusion has changed over the years. When collusion occurred in the 70s and 80s, there was still a genuine desire to produce quality software, but there was genuine error or emotional denial in failing to recognize that a project was in trouble. For example, I believe that this was the case in the demise of Digital Equipment Corporation, described below.
In the 2000s, the nature of collusion is much more destructive. It's Gen-Xers forcing their view of cookbook programming on their Boomer managers, with the result that danger signals are being ignored until it's too late.
The news is not all bad. I gather that the average project size has gotten much smaller in the last ten years, which means that more projects can be handled with cookbook programming, as long as they don't run into trouble.
There have been methodologies developed to circumvent collusion, but they require very tough management enforcement. The most important is being called "Agile software development," which demands a very short release cycle in a collaborative work environment. When it works, it circumvents collusion by forcing multiple release dates to be met, and missed release dates to be visible higher up in the organization.
Collusion, contempt and corruption are the 3 C's that I identified in my recent article on "Operation Malicious Mortgage," an FBI program that indicted hundreds of people across the country for mortgage scams.
As we've discussed many times, these mortgage scams have been pervasive throughout the entire financial and real estate industries, from top to bottom. The only possible explanation for this massive fraud and corruption is generational -- the lethal combination of stupid Boomers and destructive Gen-Xers, willing to screw anyone for their own personal gain.
There's no reason to assume that the fraud that pervades the finance and real estate industries doesn't also pervade the IT industry. After all, the same generations work in all of them.
And once again we have the lethal combination -- stupid Boomers who can't lead or manage, manipulated by nihilistic Gen-Xers with contempt for anything but the simplest cookbook programming methods, and a willingness to collude just to screw the customer and extract as much money as possible, even for a failed project.
In such an environment, everyone is required to collude, to play along. Anyone who points out that a project is in trouble is a danger to the entire scheme, and must be dealt with harshly, and fired.
I saw this recently when I recently applied for a job with a large software and consulting firm. I was being interviewed by two managers, and in response to some questions I told the Fidelity story (summarized above) and that I feel that it's my professional duty to tell my manager when I believe that a project is in trouble.
At that, the two managers looked at each other, and terminated the interview. When I wrote an e-mail message to them, expressing confusion and asking them to give me some feedback about what happened, I didn't even receive the courtesy of a reply. My conclusion is that the 3 C's are alive and well at this particular firm, and probably many others as well.
In an article last month, I asked readers to comment on the problem of managing Boomers and Gen-Xers in an IT environment. Here are some of the responses.
|
I struggled with that myself and finally got it through my head that they see it as Challenging My Authority! Disagreement seen as mutiny. And saying it won't fly seen as disagreement. A very alien mindset ,but apparently one that has to be taken into account, rather like minefields in the corporate building."
Question: Why is it disloyal for a programmer to tell his own boss that a project is in trouble? Answer: Because that would force the boss to tell his management that the project is in trouble, and may result in cancellation of the project. Dishonest collusion becomes a job requirement in many firms.
Here's another suggestion from a web site reader -- a Gen-Xer:
This is cynical Gen-X advice, but may be the most realistic for many people. Another web site reader gives similar advice:
If you are sure a project is truly moribund, leave it, but very very quietly. Do not tell ANYONE the real reason. Not even very much later."
That web site reader has the same cynical advice. He adds the following:
Here I partially disagree with him. This might work if you're a Gen-Xer, but it won't work if you're a Boomer working for GenX managers. They'll hate you for trying to be the savior, and they'll sabotage you.
As an IT consultant, I've had dozens of clients over several decades, and I've seen enormous project and company failures for the reasons that I've outlined here.
In 1994 I worked at Digital Equipment Corporation and saw Boomer managers and programmers lying to the vice president about the status of some of the programming projects. The company collapsed within a couple more years and was acquired by another company.
By contrast, IBM succeeded and grew in exactly this same time period. IBM management was aware of the dangers of collusion -- after all, this was the company that developed OS/360 -- and they found a way to manage it. They succeeded where DEC failed.
At General Dynamics several years ago, I worked on a large internet infrastructure project. Integration issues were totally ignored in the planning stages. Individual components were developed over a one year period, and it was assumed that all the components would automatically work together. When they didn't, the project struggled on for another 1½ years before being canceled completely, wasting tens of millions of dollars.
In 2007 I worked for Digimarc Corp., a manufacturer of drivers' licenses for a number of states. Their entire software development group had resigned, and for a period of four months, I was the only software engineer working on their core software. I implemented the latest technology and met all requirements for their customers (State of Texas and State of Virginia).
The supervisor, Danielle Batey, and her manager, Jeff Hamel, were Gen-Xers who had no idea how complex their own software was, who adopted the worst of cookbook programming attitudes, and who were nasty, hostile and contemptuous whenever anyone said anything to them. Once I had completed all the customer requirements, Hamel and Batey worked with the Gen-X HR manager, Shirley Webster. The three of them fired me based on completely phony claims that I can disprove with documentation still in my possession. I was completely shocked by this, because I had just written something like 15,000 lines of code (in C and C#), and I was the only person familiar with the company's mission-critical code. It would take a new programmer several months to learn the system that I'd developed. I had expected to continue developing software for several customer releases due almost immediately, but now Hamel, Batey and Webster were committing corporate suicide.
Hamel escorted me to the parking lot so I couldn't talk to anyone, and I asked him, "Doesn't it matter to you that I've developed all your core software with the latest technology and met all your customer requirements for the State of Texas?" He smiled as if gloating and said: "It doesn't matter what technology you've developed. You're too gloomy to fit in here."
You may think I'm joking, Dear Reader, but I'm not. This was happening in August, 2007, when the major worldwide credit crisis was beginning, and I had warned a couple of people to sell their stocks. Furthermore, I had called up Digimarc's CFO Mike McConnell to outline the problems with CDOs, and to warn him to make sure that all of Digimarc's investments were safe. This is the reason that Hamel called me "gloomy," and why he and Batey and Webster had decided to fire me, even though I was the only one who understood their software. And as regular readers of this web site know, all of my warnings have turned out to be right.
And this was all done right under the nose of the company president, Bob Eckel, whose office was right down the hall. Eckel had shown maximal lenscap blindness: I was the senior (and only) software engineer working on the company's mission-critical core software. I had several informal conversations with Eckel, but he never once asked me anything about how the project was going. In fact, the company's entire upper management was completely oblivious to what was going on, including the CEO Bruce Davis. Of all the dozens of companies I've ever worked for, these people and this company were the nastiest, and had the most poisonous culture.
Just as Digital Equipment collapsed and was sold off, it appears that the same thing is happening to Digimarc, not at all to my surprise. The company has never fully recovered from firing its senior engineer for being "gloomy," and was unable to meet its commitments to its customers. It's now being acquired by L-1 Identity Solutions, another manufacturer of drivers' licenses. Hopefully, Digimarc's new management will clean house and substantially improve the corporate culture, and will get past the cookbook programming mind set.
Any Gen-Xers reading this may be thinking, "None of this matters. Boomers deserve anything they get." That's the essence of Gen-X nihilism and destructiveness. Hamel and Batey may have gotten a great deal of emotional satisfaction over screwing a Boomer, but in the end their technical decisions were dead wrong. In fact, I was right not only about the financial predictions, but about all the technical decisions as well. Hamel and Batey, and Eckel as well, were wrong about everything. It's incredible that they would destroy their own company, which apparently they did, just to get the satisfaction of screwing a Boomer, but that's what happened. On the other hand, if they had listened to me and let me continue the job that they had hired me for, then Digimarc might well be a prosperous, thriving company today, instead of being sold off.
From the point of view of Generational Dynamics, that's the pattern for generations like Generation-X in the Nomad Archetype. They get satisfaction from destroying what came before, but the destruction backfires and turns into self-destruction. Historically, the Nomads who survive the subsequent crises (financial ruin and war) turn out to be the most bitter and most reclusive in their elderhood of all the four generational archetypes.
(For information about generational archetypes, see "Basics of Generational Dynamics.")
And this is perhaps the entire point of this article. The biggest risk factor in any organization today -- in finance, in IT, in government, or elsewhere -- is the enormous disconnect between Boomers and Gen-Xers. This problem must be recognized and managed if project failure is to be avoided.
There are no easy solutions to the generational problems in IT, just as there aren't any easy solutions in finance. The fraud and corruption in finance has caused a worldwide credit crisis and a worldwide foreclosure crisis, and is about to lead to the greatest financial disaster in world history.
|
I don't claim to have the answers in this article, but I do believe that the answers exist. For example, DEC was failing in 1994 through lenscap blindness, after the founder Ken Olsen had left the company, leaving the company directionless.
IBM was also failing in 1994, but the company turned around when Louis V. Gerstner, Jr. became CEO. Gerstner refocused the company on customers, and recharged the company to get past the failures of the Boomers, something that DEC could never do. As a result, IBM succeeded where DEC had failed.
There are successful IT companies today, and I believe that they're successful because they face up to the generational problems and manage them.
I can't give examples without more research, but I'm going to continue researching this issue, and I'll be writing more about it on this web site. In the meantime, expect more IT project disasters to occur, just as there have been numerous finance disasters. The worst is, unfortunately, yet to come.
Further input from web site readers is welcome.