Descended from Doublespeak, CorporateSpeak is a subject that I have learned to love, mainly for the endless amusement that it offers when the latest euphemism-ridden email makes its way down the corporate food chain. I used to think that I would parody the communication style in response, but it would be way too easy - as a colleague of mine pointed out last week, it is no challenge whatsoever.
Daniel Pink has written about this subject recently in the Daily Telegraph. I also found this blog posting on the subject at 37Signals.
CorporateSpeak is one of the key reasons why many senior leaders in large corporations have limited credibility. Its use reinforces suspicion that the leaders live in a bubble, a parallel universe where plain language has been discarded, replaced by a bizarre language that obfuscates, de-personalizes all decisions and diffuses accountability. The net result is that most readers of CorporateSpeak communications briefly scan the communication, either laugh out loud or shake their heads, and promptly consign it to the trash bin. Whatever objective lies behind the communication remains unfulfilled. Of course, that assumes that the objective was to actually say something useful. The cynic in me wonders if the underlying objective is indeed to say nothing, while justifying the existence of the "stone tablet" style of communication.

Link: http://www.emergingleader.com/article24.shtml

This article eloquently explains why leaders can command respect by their actions and values, but demanding respect is likely to get them nowhere fast...
I have been seeing a small-picture example of this at my current employer, where at least two Vice Presidents who run blogs have been having their Admins. moderate comments in order to make sure that they are "respectful" and "constructive". The challenge with this is that any pointed comments get screened out (and, with the senior leadership remuneration off the charts while layoffs continue at the sharp end, there were some people who were inclined to draw attention to this reality gap).
The demand for "respect" is totally at odds with social media precepts, where the initiator of a conversation doesn't get to control it, at least not if the idea is to have a conversation. Sure, it is their blog so they could argue that they can do what they like. However, just because you can do something does not mean that you should. Especially not in a social media landscape.
My conclusion is that the VPs in question have not worked out how to engage in a dialogue in any social media sense. They want to control the conversations, and have limited interest in any comments that they perceive as negative or at odds with their worldview. The result of their approach and attitude is that their blog traffic has dropped over the last 18 months as they have driven away a number of commenters, including myself. While it is tempting to personalize their lack of willingness to move out of their comfort zone, there is a bigger issue here. If this is representative of the attitudes of senior leadership on a broader front, it has the potential to damage the corporation by only exposing leadership to people who merely reflect their own opinions back to them. Experience shows that many great innovators and creative thinkers are regarded as pains in the ass by many people that they come into contact with. Al Bernstein is on record as saying that there is often a very small difference between "gifted" and "having a bad attitude" for creative people in corporate situations. As Robert Sutton observes, corporations need to be hiring people who make them uncomfortable...Circling back to the respect angle...one of the worst managers I observed from a distance was a newly-promoted project manager whose mantra (he was fond of it, so he said it frequently) was "I would rather be respected than liked". His challenge was he was neither. His demands for obeisance and conformity fell on stony ground with his team, who saw him as a bully, and his team members fled for other jobs inside or outside of the corporation. Eventually his leader informed him that he either needed to change his approach or go ply his trade somewhere else, and he wised up and stopped hectoring and bullying his team. However, I concluded that his pervasive need for "respect" was merely code for his need to have everybody do what he said, a leadership style that generally only works in wartime, and then only for short periods of time.

Here is an anecdotal observation; in the last 3 years, all of the delivery groups that I have supported in my employer have seen a drop in delivery and support maturity.
The drop is (I believe) being enabled by a highly competitive market, where corporations are buying only on price.
First example: on a recent sales pursuit I was involved in, I had to sit and listen to the sales architect intoning the mantra "if that is your price point we will not be competitive" every time we presented a testing team model for inclusion in the deal. The consistent demands that we reduce our base cost led to us solutioning an unbalanced team, with few experienced resources and a lot of new and barely skilled resources. We won the deal, and began to transition work from the client to the offshore team. However, given that this was an offshore team, we also ended up with the predictable attrition issues appearing within a matter of months, with one of the experienced team members leaving and two others moving to better paid jobs. This was apart from the dubious quality of a lot of the work that the team was producing.
Second example: On a more recent delivery program, I soon discovered that several major roles for a delivery team of that size were totally missing. We had no Business Analysts, no Configuration Management team, no Requirements Management process (a colleague and I had to rapidly create one), and no Testing team, until myself and a colleague were parachuted in after the client had spent 2 months beating up the temporary Testing Manager (who must have been in the wrong place at the wrong time when that role was assigned to him). I phoned up a delivery manager on the program who I knew from a previous life, and told him that I could not see the roles in the team anywhere. His response was a long sigh, followed by "I know...", then he told me the sorry story of how the roles had been in the original delivery model, but had been removed prior to the signing of the contract with the client. Clearly the intent was to save money, but all it did was deflect essential work to other resources, who in some cases were not equipped to bridge the gap. For example, the use of technical team leads instead of Business Analysts did not work at all well when dealing with the client. Client Business Analysts would ask questions about the solution to the SME's who would reply with technically-focussed answers. I would then spectate as the two sides realized they were fluent, but in different languages, and a dance ensued as both sides attempted to reach a mutual understanding, sometimes successfully, sometimes unsuccessfully. The delivery program in question morphed into a "death march" program marked by hideous over-work, failures in testing and QA due to missing fundamental processes, and continual delivery delays due to lack of agreement on requirements and schedules with the client. Eventually so many people became burned out that finding people who would just answer the phone became difficult. It was not a happy delivery.
I remarked to several people on that program that it looked and felt just like a 1980's era delivery. In the UK at that time I became wearily familiar with out of control projects where fundamentals were not being addressed, and as a result the projects seemed to become endless sinkholes of continually expanding timelines, costs and burnout. We are back in that era, if my recent experiences are representative of the delivery landscape, at least in the USA.
The more interesting question is whether delivery maturity will rise again as we leave the recession. The current fashion for offshoring just to save money in the short term is likely to remain a powerful driver for IT decision-making in the near future.
I see little prospect for wide improvements until corporations stop offshoring just to save money. That approach reminds me of the infamous client-server boom in the 1990's. Supposedly expensive dinosaur mainframes were going to be replaced by cheaper "snap-fit" small-server solutions. On paper, the cost savings looked impressive. That was, until mainframe costs fell dramatically, and the terrible truth dawned on I.T. departments that the new infrastructures were expensive and complex to build, manage and support, and the "snap fit" ideas didn't really work too well. Snap-fit is still not really here either.
An awful lot of work still takes place on those pesky "dinosaur" mainframes. In the meantime, I see a lot of delivery programs lurching from one crisis to another, caused by lack of proper delivery process modeling at the outset, optimistic timeframes, and a desire to keep costs down to remain competitive. In other words, we are building down to a price, not up to a quality level. With some of the defective staffing models I am seeing, I am not convinced that the teams could build to any quality level anyway - they have no effective Quality Measurement processes in place.

Robert Sutton, author of "The No Asshole Rule" (among other books), has an excellent article in the McKinsey Quarterly (free registration required) that talks about how good leaders can create a better climate in their corporations. The article appears to be an extract from his most recent book.

As a previous post explains, I am a night owl - I like to get up late, go to bed late, and I work best in the afternoon and early evening.
Accepting that this is a fundamental part of my DNA (and as this article in the New York Times explains, it is probably that this runs in families; my sister is also a night owl), I determined a while ago that rather than making myself miserable by trying and failing to address all of my weaknesses, I would instead focus on playing to my strengths. The NYT also has an amusing blog posting by a father who is a Night Owl, as he wrestles with the conflicts of dealing with small children who get up really really early...
Right now, I have some opportunity to play to the Night Owl part of my DNA, since my current client is headquartered in California, which is 2 hours behind Central Time, thus allowing me to commence work later in the morning. Murphys Law suggests that I will soon get a client working on EST, which will increase my stress and allow me to engage in a futile attempt at addressing one of my weaknesses...

This can be found here. I have heard a number of these in the last 10 years, over here in the USA.

I have now being working on offshoring initiatives on and off for 3 years now. I have worked on defining processes for moving work from one location to another location, recruited offshore resources for a testing team, and managed that testing team on a daily basis.
Offshoring initially developed as a cost arbitrage policy for shipping work from high-cost countries to lower-cost countries. Despite the industry and employer spin of using Orwellian phrases like "Best Shore", the reality is that work is being moved from countries that are perceived as having a higher cost base to countries with a lower perceived cost base.
I believe the whole approach ignores the reality of the immaturity of the I.T. industry, which is really only 40 years old. Those of us with more than a few years experience know that the industry has faulty institutional memory, a terrible track record for learning from mistakes, fundamental blindspots that it seems unwilling to address (like using natural languages to try and define Requirements) and a woeful inability to manage delivery programs and projects to stay within budget and deliver promised benefits.
At the same time, the preferred offshore locations (India, China and Eastern Europe) are even more immature, with no long-term track record of supporting I.T. solutions, and a large number of enthusiastic, talented but inexperienced software developers and leaders. Just one example: when I was trying to assembled a software testing team last year for a U.S. client, I interviewed nearly 20 people from our India subsidiary. The oldest resource I interviewed was born in 1976, and only one candidate had more than 5 years I.T. experience. When I asked them about what they would do if a testing project fell behind schedule, their whole mindset seemed to be predicated on working more hours when issues were discovered, rather than trying to work smarter. Not one candidate talked about reviewing processes to determine if they could be made more efficient or effective.
Under the current offshoring model, we are shipping work out of one immature industry context to an even more immature context in a geographically distant country. If you performed a properly structured Risk Analysis on that proposed action, what do you think the results would be? Right now, the decisions being made are being based largely on cost arbitrage (day-to-day running costs) and fashion.
The sad reality is that Account Teams in I.T. Service corporations may also be conniving in this race to the bottom, by agreeing to contracts that require ongoing cost reductions within the framework of equivalent service. Are those cost reduction profiles supported by any empirical evidence that shows they are achievable, or is this based on the "we'll find a way" school of unsupported optimism? And are we simply following the herd? If we are, we are indeed condemning ourselves as a corporation to perpetual mediocrity. If you are a technical I.T. contributor, the bottom line is that the Account Team in most contexts no longer looks like your friend. They almost look like an extension of the customer, working for the "other side". This is terrible for corporate cohesion.
Anecdotally, a lot of offshore support teams are marginally capable of supporting solutions. Their overall lack of I.T. experience leads to a lot of onshore hand-holding from US-based staff. However...with the current US recession, this additional work is being largely hidden from view by requiring staff in the US to work "as many hours as is needed to get the job done", with the unspoken implication that team members who do not sign on to that work ethic will be removed and replaced by people who will. When the recession ends, this excessive rework and supervision may become more visible, as I.T. staff push back against working 14 hour days by changing employers. However, right now I believe that the negative issues associated with offshoring are largely being papered over by corporations whose leadership narrative is powerfully based around offshoring to save clients money. Any competing narrative that conflicts with that story will be unwelcome. Personally, I have been informed once already within my current employer by my leadership chain that messages from below to leadership that there are issues with offshore delivery and support are likely to be tuned out.
While discussing these issues with a fellow architect, he postulated that one idea that corporations should be looking at is to set up and nurture onshore "Dream Teams". We jointly defined a "Dream Team" as a small, highly skilled and experienced collection of highly motivated individuals, using extensive automation for software requirements gathering, development, testing and deployment. Such teams would be deployed in situations where quick response and high-quality delivery is essential. Many corporations have a lot of onshore individuals that could be members of one or more "Dream Teams". The main challenge with this idea is the current offshoring mindset in both my employer and our customers, where the answer to any issue appears to be "offshore it", and then everything is structured to get to that initial answer.
Here is an interesting article from a periodical which discusses the phenomenon of Backshoring - the return of work from overseas to the country from which it was originally migrated.
Since Backshoring is very much "swimming against the tide" and also represents an admission of offshoring failure by a corporation, I expect these stories to be largely hidden from view in many corporations.

Ever since I can remember, I have been a night owl. This often gives me challenges. Most corporations, especially in the USA, are set up around the "morning lark" model. I have encountered the chill wind of disapproval from morning larks many times in the past when I roll into work and the larks have been working for 2-3 hours already. The fact that I am still working when they are flaked out on a couch somewhere is something that they seem to have a large capacity to ignore.
This is an entry to a collection of discussions around the morning lark vs. night owl differences.
It is possible to form symbiotic working relationships with somebody who is opposite to you on the sleep and work spectrum. Many years ago in the UK, I had an extremely productive working relationship with a fellow project leader. She was a classic morning lark, she was in the office by 6am nearly every morning, but left by 4pm, and, by her own admission, her brain ceased to fire on all cylinders around 3pm. We would meet together to work issues and set direction from 11am until 2pm, after which time I stayed away from her, since she would be winding down and not at her best. She would stay away from me until 11am, since before that time my brain was not firing on all cylinders. This worked well for our time together.
One comment that I will make is that having a partner who is the opposite to you is probably going to require some sensitive management skills...
UPDATE - Thanks to David Rendall for passing on a link to this article in the New York Times that discusses the larks vs. owls issue and its relationship to the circadian rhythm, which is the body's own internal clock. I remember that a university in Europe conducted research on circadian rhythms many years ago, using college students who were studying for end of year exams. This was a great example of a symbiotic relationship; the students needed a place free from distractions to study, and the research group needed a group of subjects who were prepared to be placed in a secure environment where they could not determine what the time was. The findings of the study were that most people, deprived of time reset cues based on clocks or the appearance/disappearance of daylight, tended to freewheel on a longer day length than 24 hours. In some cases, the students were 2 days behind the actual date.
In my own personal case, I wake up when exposed to daylight. My bedroom has to be very dark (we have blackout curtains). I have concluded that I cannot live in Alaska or Scandinavia, because if I do I will be awake (and miserable) 20 hours a day in the Summer and in virtual hibernation in the Winter. Most likely I will spend 6 months a year in therapy for SAD (Seasonally Adjusted Depression).

One of the interesting challenges I have encountered in the past when dealing with leaders at various levels in corporations is the phenomenon of the leader whose knowledge is deficient in a key area, but who publicly (at least) refuses to recognize this. Quite often the leader rises to high office without addressing the deficiency. Logically, you would think that they would (a) realize that they lack knowledge or skills in this area, and (b) hire somebody to focus on it. In reality, most of the time, they do not try (b). However, more bafflingly, they often appear to fail on (a).
One example is a software company that I worked for in the UK. It had been founded by a software consultant and he built the company up to 75 employees in the UK and 75 in the USA. However, soon after I joined, he lost the leader who held together the consulting group of the company, and who had been instrumental in persuading me to join. The guy quit and went to work elsewhere. The founder's comment to another employee who pointed out that the guy was an excellent people manager was revealing. He commented "I really don't know why we need a man-manager. Everybody should be able to manage themselves".
In the case of this entrepreneur, his comment was a symptom of a wider feature of his worldview, namely, that everybody else would be much better off if they behaved exactly like him. However, the basic problem remained, namely that he lacked an appreciation of empathetic, people-centered leadership. Ultimately it contributed to his inability to grow the business, and led to his eventual departure, since in the meantime he had sold the business to a US corporation who expected profitable, continuous growth.
More recently, I worked for EDS during the end of the Dick Brown era. Dick was a deal-maker, he had no real interest in operations and execution. He got excited about the next big sale or deal. As a result, execution processes (starting with this pesky little thing known as due diligence) were neglected during his period as CEO. The inability of the corporation to execute on poorly-structured and optimistic deals signed by him was a major contributor to a crash of the stock price, and his credibility declined thereafter to the point that he was forced to resign. Once again, a leader was undone by his failure to provide any focus on areas that he himself had little interest in.
As a positive example of how you should manage, one can point to Microsoft during the period where Bill Gates was the CEO and Steve Ballmer was the COO. Gates' visionary ideas, unbalanced by his awkwardness in public, lack of interpersonal skills or interest in minutae were balanced by Ballmer's ebullient, street-fighter personality and focus on operational details and execution. Gates was smart enough to realize what he was not going to be any good at, and in Ballmer he found a personality to perfectly complement his own.
Over the years I have come to characterize people with this leadership deficit by the summary "they often don't know what they don't know, but if even they do know they assume it is unimportant, and therefore can safely be ignored". Needless to say, it is frustrating to deal with such people, since every time you try to draw them into a discussion of the "black area", they lose interest and then it is hard to avoid them shutting you down. I even invented a phrase to summarize this behaviour pattern when applied to software developers, many of whom labour under the dangerous delusion that they are qualified to design a user interface, when in fact they would be downright dangerous in any form of Human-Computer interaction design role.
It turns out that my purely anecdotal observations are also paralleled by academic observation and research. The pathology is part of a wider pathology where people become convinced that they are good at something even when even the most favorably-disposed observer can see that the reverse is true.
Specifically, David Dunning and Justin Kruger conducted research after Dunning wondered whether it was possible to measure one’s self-assessed level of competence against something a little more objective — say, actual competence. He and Kruger published a paper, “Unskilled and Unaware of It: How Difficulties of Recognizing One’s Own Incompetence Lead to Inflated Self-assessments,” in 1999.
This multi-part article in the New York Times blog discusses the research and the phenomenon in more details.

Dunning and Kruger argued in their paper, “When people are incompetent in the strategies they adopt to achieve success and satisfaction, they suffer a dual burden: Not only do they reach erroneous conclusions and make unfortunate choices, but their incompetence robs them of the ability to realize it. Instead they are left with the erroneous impression they are doing just fine.”
It became known as the Dunning-Kruger Effect — our incompetence masks our ability to recognize our incompetence.

This could perhaps be the origin of the old saying "ignorance is bliss"...
The article on the New York Times blog is actually a long article about the wider phenomenon of anosognosia - the inability of people with body deficits such as paralysis to even recognize that they have the deficit. To an outsider it looks like a particularly extreme case of denial, which of course it is. The last part of the article contains a nice Venn diagram summarizing the extremes of self-delusion into which we can all fall, with denial in the center.

I am not sure if I should help with this...