Friday, March 30, 2007

"No Jerks Allowed"

Businessman yelling at coworker with megaphoneThe most recent issue of Time Magazine brings an article titled "No Jerks Allowed". It is an interesting perspective on a trend of the same name in the workplace.

The author hit a misguided note while putting brilliant, albeit abrasive, bosses in the same bag as the office variety bully; but I quote a passage that made me laugh out loud:
An IT company he mentions went so far as to calculate a star salesman's TCA--total cost of a**hole--by totting up expenses attributed to his behavior. Turnover, legal bills and anger-management courses rang up a TCA of $160,000. So the company jerked some of the jerk's bonus.
The online version of the article also has a link to a priceless "self-test" quiz.

Saturday, March 24, 2007

The Web 2.0 Revolution, Email Privacy, Tequila and Handguns

"Computers have enabled people to make more mistakes faster than
almost any invention in history, with the possible exceptions of
tequila and handguns."

Mitch Radcliffe

In these days of twittering, messaging, e-mailing and blogging, collaboration technology is driving a revolution in the workplace. Unconstrained information flowing instantaneously across geographies at the touch of a button, duplicated and replicated effortlessly.

And yet, not of all us are ready for it. In the shadows of our hurried schedules, every day a muffled voice is dragged into the back alleys of our virtual world and strangled without mercy: privacy. In modern days of immediate satisfaction at the click of a button, privacy is treated like a nuisance, a lengthy bureaucracy standing in the way of immediate communication.

Years ago, governments felt compelled to regulate the privacy agreements between companies and the general public. However, within corporations, communication through e-mail or messaging is still far from the protection of a client-attorney privilege or patient-doctor confidentiality. There seems to be enough reason to introduce some of those principles into the exchanges that occur inside the workplace.

Finger pressing e-mail button Whether it is the oblivious colleague who tears the work environment apart by exposing the content of a would-be private messaging session or an aggravated peer forwarding a note to someone who will not take it well without the proper context, collaboration technology is the perfect partner in crime for virtual trespassing.

When an employee shares information with another employee, the company owns that information, no one else. There is no doubt that in most cases the source of information would gleefully allow the information to be freely shared, but not in all cases. On the one hand there is the innocent note with links to project resources, on the other hand there is the controversial note containing opinions or the unfinished design document containing transient information that will be misinterpreted outside the design team.

Because common sense isn't, it seems imperative that collaboration tools somehow incorporate privacy respect into their workflows. The more obvious requirements, in order of importance, would be:
  1. Allow the source of information to approve the sharing of that information
  2. Support generalized pre-approval for less sensitive content, such as presentations or public contact lists
  3. Support the notion of authorization expiration
  4. Allow the source of information to be notified about the sharing of its information
I do recognize that some of these suggestions may seem counter-productive at first, but I am also familiar with the horror stories that could have been preempted by simple check boxes. On the long run, the averted productivity losses caused by privacy breaches would far outweigh the cost of a couple of clicks. These simple measures would also help rebuild the endangered trust so much needed on any collaborative task, virtual or not.

Saturday, March 17, 2007

Friends, enemies, processes, and the law

A long time ago I read a disturbing quote in a news article. It stuck with me for its arrogant candor and the way it describes a cyclic loop between cause and effect:

For my friends, anything; for my enemies, the law.
-- Oscar R. Benavides, President of Peru, 1933-1940

Two military coups adorn Oscar's otherwise unremarkable biography, but this entry is not about presidents, it is about processes.

Throughout our careers we are often entrusted with the responsibility over services, solutions and products, which also include the task of owning their requirements management processes. Not being a military president, it is usually in good taste to avoid hanging a frame with that quote on your wall or adding it to the home page of your project web site. Fun, but not in good taste.

Despite one's best efforts to maintain an impartial stance towards the process, the source of a requirement is an overwhelming factor when assigning priorities. It does not take long before a divisive line forms between those who get more of their requirements answered and those who get stranded in the "futures" bucket. Once the separation line forms, it is also not long before you have the equivalent of friends and enemies in your hands.

In fact, attempting to equally include the requirements from all sources is not a sound practice, but a guaranteed way of creating an offering that will not please anyone. There is a lot to be said about the open-source model and its way of allowing the people neglected in the prioritization process to contribute their requirements, but there is always a limit on how open a project can really be.

Barring infinite resources to implement all requests, it seems to be a good idea to rotate the owners of an offering every couple of years; even more so when resources are scarce and the populace of the discontent stops distinguishing the process from its owner.

The process may be even more grueling while developing shared components in a large organization, where the somewhat direct access between the lines of management allows people to manifest their discontent through escalations. When resources are really scarce, the project owner soon finds his time consumed in justifying his choices or creating elaborate reports on why certain requirements cannot be implemented.

Once management chains are involved, the technical evaluation process starts to suffer from a quota-based approach where there are no longer friends and enemies. The entire user-base becomes an amalgam of former-friends and truced enemies; the first displeased by the politically-induced loss of status and the latter by a handful of requirements forced into the product at gun point.

Wednesday, March 07, 2007

Failures, reasoning and rationalization

As I prepare to write this entry, I have my mind immersed in darkened thoughts about what we bring upon ourselves whenever we fail at something.

It is not failure itself that worries me; it is how we choose to deal with it.

Rationalization is at the same time the easiest and the worst way to respond. Good natured rationalization is either self-inflicted by our need to quickly get through a momentary loss or directly offered by a colleague who does not want to see us demotivated.

My suggestion is: ignore your instincts and peers and **feel** the pain. That may sound incredibly naive but you have to feel it in the right way. Feeling pain is not about going to a corner and sulking for an hour, it is about accepting that things went wrong and studying what went wrong to be prepared for another day.

What is devilish about rationalizing failure is hidden in the Latin root of the word itself: "ratio". When we rationalize, we create a relationship between two or more things. When we rationalize failure, we invariably create a relationship between the failure and something good. Given time, a good rationalizer can bring himself to believe there was no failure at all, after all "look at how much we have learned", "how much worse it could have been", or "how it was a better attempt than the previous one".

Given time and enough people, rationalization becomes a culture, and a bad one at that. For socially acceptable reasons and just good behavior within a functional team, no one is supposed to declare a failure other than the owner of the task at hand. It is upon the owner of the failed task to declare it a failure and look up to his peers to help him reason as to what went wrong and how those same mistakes can be prevented in the future.

Failing that act of self-immolation, we are left with the worse alternative: When the owner of a failed task does not declare it a failure, **the team still knows it**. Trust is broken. Managerial evaluations compound to the problem in that no one wants a failure in their record when they know that their peers will not be as forthcoming about their failures.

When nothing is admitted as failure, there is only one outcome: success. If people do not feel like they can admit their mistakes, they have only two choices: succeed at everything or declare everything a success. Of course loose objectives are a great aid to successful people in that there is always wiggle room to define success. The dooming mechanics unfold quickly after that point, with declared success being easier to achieve than real success.

Whether one ever reaches a degree of career stability or maturity in life where they can admit their mistakes, it is a very personal question. Very few people can answer that question one way or another.

This posting is not a eulogy to failure; there is no organization that can indefinitely sustain repeated failures. However, it is my belief that the only way to preempt a string of failures is to admit the first one.