Wednesday, July 30, 2008

Another office delta

At the new place, nobody has any mission statements or any other corporate propaganda decorating their cubes. What's up with this place?
Why aren't there any laminated cards showing the leadership traits that everyone has, my favorite is integrity... because, well...let's just say that I believe it is very challenging for many manager managers to do what is asked of them and act with integrity towards those below them.
It comes out in conflicting messages. We saw that in the communications regarding offshoring and the mandatory intelligence tests at my previous company.

Healthy jobs and health insurance

I'm sporting the two badge look this week as it is my first week in my new job and the last week at my old job. I'm going through "oohing" and "ahhing" at all the shiny cool new stuff at my new job and saying good riddance to all my pain points at my old job.
One observation I've noticed is my new client is committed to the health of their employees. Some of the perks are as follows: defibrillators on every floor, on site gym, a martial arts studio, on site massages, and fresh fruit in the break rooms. Additionally, I learned that the company gives people 4 hours of PTO if they use the gym a certain amount of time within a quarter. If they meet a yearly goal they get an extra 8 hours. That's 3 days of vacation for working out. FTEs are permitted to use some of their work time to work out. I'm impressed by the company's commitment to their employees health and well being. I'm also glad they let contractors like me use their facilites. They won't let me bill for it though, bummer.
That's really cool. The people here seem a lot healthier than at my old job.
At my old job, we had at least three people die this year and a lot of people just don't look very healthy.
The company tried to address this by holding a health awareness day where people could get free blood tests and take free mandatory online health surveys. No onsite anything. If you want fruit, go buy some in the cafeteria. What do you think this is a fortune 134 company?
For a health industry company, they also don't do a very good job with health benefits. The company encourages its employees to elect for a consumer 'empowerment' plan. I think my friend Dale Mensch has it right when he opines that when the corporate types use the word empower they really mean disenfranchise.
The empowerment plan scared the hell out of me. Sure, the company gave my family a $2,000 allowance for the year, but once you use that up, you're basically on your own until you hit the catastrophic part of the policy. Colleagues of mine who have had medical emergencies found themselves owing tens of thousands of dollars.
We just don't have room in our finances to handle something like that. Who would?
I think that a consumer driven health plan isn't the perfect solution. It gets sold with the halcion memories of our parents paying cash for our trips to the doctor. Weren't those days great? You didn't have people going into the emergency room for a cold or calling an ambulence for a bee sting or any of the other poor decisions people made when they had no out of pocket expenses for their health care.
Consumer driven care does force people to make choices, what it also does is discourage people from seeking care. There's the 100% preventable coverage part, but it isn't as good as it sounds.
Under a consumer plan I can get a physical free of charge. If I were to mention that my back is bothering me, that's considered treatment and everything relating to my back is not covered under the preventative--a few tests and a big chunk of that $2000 allowance is gone.
A few burns through an allowance and people won't seek care that may improve the quality of their lives. People don't make great decisions when it comes to weighing their health and money. Every time they seek care they have to be wondering whether the trip will devastate their finances.
Life is stressful enough. People shouldn't need to worry about their health and the cost of their health care.

Thursday, July 24, 2008

The most important lesson I learned working with a chief architect

A number of years ago I had the opportunity to work with my company's chief architect fixing a defect in a product.
The chief architect was widely respected among the developers. Prior to the project, some buddies and I discussed how cool it would be to work right under this guy for a while. I really enjoyed the opportunity to get to work directly with him for about a month.
He taught me plenty of principals about how to make solid design decisions and how to think strategically. It was also pretty cool not having to go through the regular architectural reviews while I was working with him.
The most important thing he taught me though is that even he can be wrong sometimes. There was one API that we used in our project. It was not entirely documented, however the Chief Architect told me he was confident that it returned values in a sorted collection. In all of our tests that was the case. I had some doubts, but when he told me that he was confident I assumed that he knew.
About six months later I found out that that was not the case and a painful fix needed to be made. He was cool enough to take responsibility for the erroneous advice, but I still felt that I could have prevented the issue.
Since then I don't take people's recollections at face regardless of the level of respect that I have for them. If I am even slightly uncertain about something I seek definitive proof.

Good Read: Today's Security Matters

Is Bruce Schneier the only smart person in the world or in the security world? I ask this facetiously, but he is the only security expert who continually advocates trying to solve security problems sensibly.

In his Security Matters blog he wrote an excellent essay Lessons From the DNS Bug: Patching Isn't Enough about the flawed practice of security patching software. It's a clumsy process of trying to rush out fixes and keeping the details of the problem a secret. It's a wasteful mess.

Schneier advocates getting good security people involved in the design process from the beginning. By bringing the security mindset to the table early real security measures can be integrated into the design and the ability to efficiently and discreetly adapt to unknown threats can be built in like any other feature.

In my own experience participating in software design and development for applications that contain valuable information I know that even in these cases security is not a first class citizen. Although I make no claims of being an expert, I do try to look at systems with the mindset of someone who would try to exploit it and see how the system could be improved. I've had friends who are criminals and hustlers. From them I learned a lot about how people will exploit a system.

One of these acquaintances, a professional gambler, taught me a lot about how an opportunist's mind will work. I consider myself fortunate to learn what I did from this person. I held daily conversations with him over the course of a year. What I learned from him is he, and people like him, has absolutely no regard for rules. If he can find a way to get an advantage he will exploit it for all it's worth.

One example: he found out that Target had a generous 90 day return policy on big screen televisions. My friend purchased something like ten of them at the beginning of college football season to set up in his war room. When the return window was ready to close he returned each one of them. He had a 10 televisions for 3 months for free. He had tons of stories about exploiting a system. The stories about online gambling sites were even worse--don't be surprised if the other 7 players at your online poker table aren't on a conference call discussing how to take all of your money.

He would apply this mindset to everything he did. When it came to gambling he wouldn't place a bet unless the odds were clearly in his favor.

I don't know many people in the software industry who can think like my gambler friend besides the aforementioned Schneier. When I raise security concerns in software projects people usually look at me like I'm crazy.

When security is part of a project requirement it's usually treated like an add on or a layer to an application. Ok, we added security, what's the next feature? Many software designers think of security as a firewall, if you have that security layer then you don't need to worry about it in the rest of the design.

The way that software projects are typically set up there is no incentive up front for the participants of a project to take security into heavy consideration. Embedding security into an application adds scope and risk to a project being delivered on time. Dateality is a premium of projects.

Often times security issues become apparant during the development and testing phases of a waterfall project. Those issues are probably best fixed with a redesign, but the old patch approach really looks good to keep the project on schedule.
Until security, and the ability to efficiently adapt to changing security conditions, is perceived to be as important as the other features of a project--including delivery date, we're going to continue to follow the security patch process.

Good Essay Regarding Productivity Studies

From Lifehacker: What Productivity Studies Really Show. In a nutshell, what the author of the essay adises is take the productivity study du jour with a grain of salt. Many of them make sense, but many are also blown out of proportion. I think we agree with a lot of the sentiments of these studies. Most of them take a very plausible position and try to quantify them.
Like some of my challenges I've described earlier about justifying a cost savings measure within a vacuum, see cost of cutting cost, the real danger of adopting a course of action based on the analysis of a study is there are other factors in play that aren't taken into account.
My own spin on the issue is keep a skeptical, but open, mind when you read pursuasive materials. Ask questions and do some analysis on your own.

Wednesday, July 23, 2008

Groovy Metaprogramming Pecha Kucha

A few months back the Groovy Users of Minnesota prepared a Pecha Kucha presentation about metaprogramming with Groovy.
http://www.youtube.com/watch?v=4XL42u7vtJ4

Hamlet D'Arcy deserves most of the credit for this presentation. He did an outstanding job organizing the group and producing the presentation.
http://groups.google.com/group/groovymn/web/metaprogramming-pecha-kucha-wip

Bentley's Blingin New Notebooks

Over at gadget lab is a report that Bentley will be producing notebook computers, called the Bentley Ego, for the very reasonable price tag of about $20,000.
More info about the systems is at Laptop World here.
Here's the thing I don't understand about the whole super expensive laptop market. Computers are perishable goods, they're only really good for a few years. Bentley automobiles are durable goods. I'd keep a few Bentleys in my imaginary fleet of exotic cars for at least five years. Seriously though, an automobile that is built to the specifications of a Bentley or Rolls Royce is something that the lucky few who can afford them keep for decades. They're built to last. The characteristics that define what makes a superlative automobile don't change much. Yeah, mileage is more important now to many people than it was a few years back. The other characteristics like comfort, safety, and style stay with a car forever.
A computer usually can't last more than about three years before they struggle to run the latest software. A three year old laptop would falter if one were to try to run Vista.
Does it matter how well a laptop is built? It really needs to last a few years before something much much better in the ways that count comes along. What do you do with a $20,000 laptop when it hits functional obsolescence?
Computers aren't like cars. Sure today's computers will continue to work for years to come, but software is continually evolving and demanding more of the computers that run them. Intel giveth and Microsoft taketh away.
Isn't that what makes software so interesting though? New things are constantly coming out. Software is more demanding because affordable computers are continuously being made available. It seems awfully foolish to drop more money than many people make in a year on something that won't work well in a few years.
I don't know what the target market is for this type of product. People with more money than sense I guess.

Tuesday, July 22, 2008

Canadian Power Trio on Colbert

By Canadian Power trio, I don't mean The Barenaked Ladies before the last two members joined or Gordon Lightfoot and the two other guys he sometimes jammed with. I actually mean Rush.
Rush is Geddy Lee, Alex Lifeson, and Neil Peart, and all three of them were on the Colbert Report. They did something really cool, they played their own song, Tom Sawyer, at Expert level on Rock Band.
Check it out.

I feel a lot better about sucking at rock band after seeing that.

I thought of something really clever to post at lunch

I thought of something really clever to post at lunch that I thought people would enjoy reading. Since then I had to go to a few meetings and I forgot what it was that I was going to post. I'll post it if I remember. Sorry about that.
--Paul


Ok, I remembered what it was on the drive home. We were talking about how some bars will serve complimentary chasers with drinks. For example, you can usually get an 8 oz glass of beer with a bloody mary or a tumbler of juice with a glass of whiskey. In some places, Boston was given as an example, they don't do this and have never heard of a chaser. I wondered if there were other places that were the exact opposite, they'd give you a chaser for anything. Or maybe any kind of chaser. Maybe they'd serve a chaser for your chaser. So, if I ordered a 16 oz. Bloody Mary, I might be able to get a complimentary 8 oz, bloody mary chaser, and with that a complimentary 4 oz. bloody mary chaser, and so on and so forth. When I'd be finished I could make a series of those russian dolls with all the empty glasses.
Fun talk. Bar owners, think what kind of business running a policy like that could brew up. You'd probably get me in there if I were in the neighborhood and thirsty.

Monday, July 21, 2008

Auditable != Secure

It occurred to me this morning that many of the security systems I've been challenged with recently aren't really security systems at all. They are auditing systems. For every piece of the production environment and every change, there must be a way for an outside auditor to track that piece or change to a slew of paperwork that explains why that piece or change is in the production environment.

Processes and rules are put into place to facilitate easy auditing. In ideal scenarios for auditors, a set of responsible parties need to authorize every change to the production environment. They do this by signing off on a set of documents that, among other things, describe the change that is going into production. The process is anything but swift. Some of the challenges that slow the process include: all approvals must be in place 24 hours before the release window, if any change is made to the paperwork the approval process needs to be restarted, e.g., if you forget one file or step on the day of release, it's likely that the release will need to be postponed. Because approvals are so regular and so frequent, approvers get into the habit of rubberstamping approval requests. People aren't good at diligently performing detailed repetitive tasks.

The inefficiency of the system is costly in terms of time, but also in false senses of security. People believe that the system is secure. I believe that psychologically people believe that an obstructive inconvenience equates to security. And to people who obey rules, the system is secure.

I know it may be difficult for many people to believe this, but there are people who willfully ignore rules. Putting procedural barriers in place of people who have no intent of following those procedures is more expensive and far less productive than having no barrier. The people who follow the procedure are less productive because the process is by definition obstructive. The system is not secure because the obstructive procedures are ignored by the "evil doers".
How do these obstructive systems break down, mostly through a casual disregard for the procedures, social engineering and incompetence.

Let's take a hypothetical system with a Segregation of Duties(SOD) policy. Under SOD, only a trusted few are allowed access to the production passwords. Those trusted few will give out the passwords by means of incompetence, social engineering, or just disregard for the system. It will happen. Once the passwords get out some people will eventually begin using them as shortcuts to avoid the cumbersome process.

The other flaw to the system is those password holders have no mechanism to keep their actions in check. One of them could go rogue and run amok.

The last rung in the ladder are the changes themselves. Any developer worth a damn could sneak code into production that has vastly different functionality than the code in the QA environment.

Those are just a few realistic scenarios. A system that relies on a segregation of those who make changes and those who put them in is not sufficient to protect a system from malice or, our old friend incompetence.

Having a system in place actually makes these situations worse for two big reasons. One reason is the perception that the production environment is secure. People may be vigilant to the obstructive processes, yet completely lax with other aspects of the system. False senses of security breed complacency. The second is the difficulty the process imposes by obstructing people from reacting to incidents that damage the production environment, regardless of intent.

Instead of relying on procedure alone I'd recommend the following practices be put into place: Develop a practical disaster recovery strategy. The better the strategy, the smaller the window for mishaps.

Next, streamline the promotion process: Make all documentation living and make approvals meaningful.

Put the power of approval into lower level people. They know what's going in, let them take responsibility for it. If there's a problem, the director will catch heat for it anyway. If directors are just approving projects without knowing anything about them, they aren't adding value to the project.

Finally if you want to see a good model for security, check out banks and industries that handle money. Banks handle money all the time. Their processes are constantly refined to avoid people from exploiting vulnerabilities in their processes. The good thing about banking and finance is, if there is a hole in the process, that's likely to be the first industry to have someone exploit it.

One idea, why not make production passwords require two trusted people to provide credentials via multi factored authentication to generate a temporary production password that is good for the scheduled window of the release. The intention is that no one person could get into production by themselves.

The system I outlined above is both more secure than the basic SOD system. Computers are powerful now, information can be tracked for auditors without requiring that people perform multiple obstructive steps. Isn't auditing really about tracking changes and making sure that an organization can explain the reasons behind any change.

Is it the mandate of the auditor that efficiency be sacrificed so they are able to do their work? If so, they're very mean people.

The Best Part About Starting a New Job

My favorite aspect of starting a new job is having a work place that is free of all the pain points that were at the old place. Everything that annoyed you about the old job is gone.
You always get pain points wherever you work, and they might even be the same. However there's a while where you're blissfully ignorant of them.
For a while, everything is new and pain free. You see every aspect of the new job and go, "that used to be very difficult at my old job." It doesn't last forever, but it sure makes the transition enjoyable.
And to confirm my theory I asked a friend of mine about what Google employees gripe. He said that they gripe about not having enough time to work on their 20% project.
No place is perfect forever.

Friday, July 18, 2008

Another brilliant idea from a friend

A friend suggested that he would like to start selling little magnetic Darwin feet as a conversion kit for those Christian car fish things. People could easily convert the fishy into evolutionary fish land creatures without damaging someone's car.
I think that it would be fun to put those legs on the cars of a few of the evangelicals that I know.
I think they'd get a pretty good laugh over it. I'm pretty sure that they would keep the joke in perspective and wouldn't dramatically overreact.

Thursday, July 17, 2008

One of my favorite ways to save money

I try to take advantage of Amazon's monthly grocery specials.
Every month, Amazon features a number of instant rebates when you purchase a certain amount of a type of product from them. For example: this month they are offering an instant $15 rebate if you place an order of $39 or more worth of select Kellogg's products. So, you get $39 worth of Kellogg's products for $24. Most orders are above the $20 threshold for free shipping.
I like their system. They give you a code, a list of eligible products and a target dollar amount. The challenge is to make an order that gets as close to the dollar amount as possible.
I've made quite a doomsday pantry of non-perishable goods and supplies through Amazon.
It's a great way to save a good chunk of money.
It's also a way that I've learned about a number of really good products.

Hypochondriac or unhealthy environment?

A surprising number of my chums, myself included, at work are complaining about being lightheaded lately. I wonder if there are air quality issues with my building.
I'll put a $5 on a Legionnaire's Disease in the air conditioning. It would not surprise me that someone thinks cleaning the HVAC system is a waste of money.

Scorecarding employees

I've noticed an interesting phenomenon when people put in their notice that there seem to be a bunch of candid conversations between the person leaving and other people who want to air their gripes with the system. Those people will ask that the resigning person to cover their own pain points. 

As a resigning employee. I have received quite a few requests to emphasize the company's current practice of scorecarding.

In a way, it's sad that it takes someone to leave for management to take notice of pain within the organization. I'm happy to do what I can to improve the conditions for my compatriots.

I've had a lot of requests from colleagues to make certain that I mention the current performance management policy.

I've talked about this before, but to summarize the policy: the individual contributors at my soon to be former company do an awful lot of work for the sake of performance management. Our senior director advised that we should spend approximately four hours a week working on performance management work, i.e., 1 on 1 with manager, team meetings, forecasting hours, time reporting, and updating our scorecards. With the exception of the meetings the performance management actions advance no cause other than to provide data points for the managers of those contributors to rank them.

Performance management work does little to make people more more performant. When contributors are aware of the criteria against which they are evaluated they make sure that they work to those points. It's an old game and it is universally played in systems where sets of data points are used to evaluate self aware people and organizations.

I liken performance management to mandatory testing in the public school systems. Because there is a test that evaluates the students, and the school, the teachers shape their content. Test standards and scorecards both narrowly define a success condition. In the case of public schools, curricula that does not advance students towards scoring well on the test are de-emphasized or eliminated.

In my company, all you need to do is make certain that you meet the goals on your scorecard. The goals are mostly time driven, or as Nate Schutta would say emphasizing dateility. You meet the date and have a project that doesn't linger in QA for too long you succeed. That's all that matters.

You could deliver an application that barely meets the customers' needs that is rock slow and painful to use and still get praised. Why? Well, the company has a scorecard of its own. The stock price, which is influenced in no small part on the company's 10Q. How does software play into this? Well, internal software development, under certain circumstances is a capitalizable. What does that mean? In my company it means that time that is spent working on a capitalized project is treated differently than other projects.

We are discouraged from working on non-capitalizable work and are rewarded for reporting time against capitalizable work.
I've been told that capitalization is the reason that IT departments are so interested in time tracking. I'm kind of surprised that someone hasn't figured out how to make all IT work capitalizable without wasting all sorts of time having the people who do the capitalizable work spend non-capitalizable time tracking time. I can see that trend coming down the road though.

But I digress, the company is held to a single number grade, stock price to evaluate success. I would cynically argue that work that advances the company towards a higher stock price through the financial reporting is prioritized over all other work. As the sludge flows downward we can see delegation of a narrowly defined set of success conditions assigned throughout the IT orgainzation. That is why I believe that our goals are so narrowly defined.

The question that nobody seems to have asked is whether working towards maximizing short term gains is in the best long term interest for an organization?
In any scenario where you have a metric that is a performance indicator, people should stop confusing the metric for the goal. Setting narrow goals or scorecarding aspects of a job is not a healthy practice. The participants who are most interested in making themselves look good will optimize their work to achieve those specific goals. Unless particular attention is paid to the goals when they are defined, the end result is going to be results that are optimized to achieve the narrowly defined goal. At least, the people who will be rewarded most are those who achieve the best scores on the narrowly defined goals.

Consider the following goal that I see in lots of organizations. The people who define the goals want their workforce to improve their forecasting abilities. They set the goal that those whose actual hours match their forecasted hours closest are the ones who are rewarded the most generously. People who are most interested in the reward will do whatever it takes to maximize their reward. In this case it's pretty easy for someone to overestimate the time and then drag their feet in the project to make the actuals match the estimate. Why wouldn't someone?

Software development, or any kind of work, is mostly a zero sum game. In software development, there's completeness, quality, and time. They are interdependent variables, if you change one of them the others will need to change.

Managing employees is exactly the same. If you emphasize one element of a person's job over the rest of the elements, the other elements will suffer.

What probably suffers the most is employees morale when they are told not to do what they know is right.

Wednesday, July 16, 2008

My resignation was announced

Earlier this week my manager announced that I would be resigning from my current position in a project meeting.
The response was unexpected to me, nothing. Not a word was spoken in the meeting. One of the engineers did give me a slightly surprised look. That was it.
The QA leader talked to me after the meeting. He's a smart guy and a contractor. He opined that the reaction spoke volumes. Nobody at my level is surprised that I choose to leave. The environment is not fun anymore to a lot of people and those people are leaving.
A few of my colleagues who have worked for this company for over ten years have candidly disclosed that they are considering pursuing outside opportunities.
I thought it was just me who is fed up. It turns out that I am not alone. There's comfort in that, and I also feel bad for those who are staying. It used to be a really good place to work.

Monday, July 14, 2008

What is in a name?

Consider the following:
What's in a name? that which we call a rose
By any other name would smell as sweet;
--Romeo and Juliet (II, ii, 1-2)
These famous words have many times sparked discussions about whether a name holds meaning. After all, aren't words just symbols for things? In the context of the play, Juliet asks whether Romeo's surname Montague holds meaning to her. Juliet is a Capulet, a feuding family of the Montagues.
To Juliet, the name Montague is negative, she questions whether it is meaningful to her. Or does she? My opinion is that she's got a thing for the young Romeo types and is going to justify hooking up with him any way she can.
Is a name unimportant? It is important to Juliet, otherwise why would she question whether it is important. If it were trivial to her, she wouldn't have asked the question.
More importantly, the meaning of the name, is also important. If it weren't important, i.e. if the families weren't feuding, well, there would be little reason for a play--then the play is just about a couple of kids who fall in love and their families support the whole idea.
My reason for rehashing freshman lit is to say that even when Juliet muses that names aren't meaningful that they are.
In real life names are extremely important. They are powerful symbols.
What do you think of when you read the following names?

New York Yankees
Duke Basketball
George W. Bush
Charles Nelson Reilly
Adolph Hitler

My apologies to the late Charles Nelson Reilly for putting him in such notorious company. Each of those names is weighted with meaning to people. It's impossible to divorce the name from some sort of emotional response.
People who follow baseball are likely to hold an opinion of the Yankees. People who follow college basketball either love Duke or know how to read. Ok, I'll leave thinking about the emotions the names evoke for the rest of the names as an exercise to the reader.
What is in the names EJB and Struts? To me both of them are laden with my thoughts on EJB 2.0 and Struts 1.2. I think about the messiness and the pain of using those older technologies. How can you not? I no longer use Struts 1.2 because there are better options out there that are easier to use and more effective. I wouldn't use EJB 2.0 on anything because there are other options that are much better.
I hesitate to consider using EJB 3.0 or Struts 2 though just because of the name. I hear the word Struts and think, I don't want to have to deal with separate form objects and struts-config.xml.
I hear good things about EJB 3.0 and Struts 2, but I swear whenever I'm in a group and somebody mentions either of them someone will confuse those technologies with their predecessor.
In both of these cases the technologies reputations preceed them. Struts 1.2 wasn't a bad thing. It is a stable and functional framework that is widely adopted in industry. People think about it negatively because we have improved on it and many of the things that it doesn't do well seem unbearable in comparison to new technologies.
Same goes for EJB 3.0 the EJB label carries a lot of baggage. To many people the name evokes painful reactions.
One question that arises is whether the negative associations with the names Struts and EJB from previous versions will stick with the product lines. Only time will tell, but it's going to take a considerable PR effort to change peoples' gut reactions.
Would renaming the version to something sexier than 2.0 and 3.0 influence people's perceptions? I dunno ditch the numbers and play with the words a bit. Maybe conStrutsion or EJ-me. I'm not a marketing guy.
By ratcheting up the number a big tick I don't think that it's being communicated how different the technology is. Is it possible to increment an established and well known technology without bringing the negative legacy?

Friday, July 11, 2008


This is a pretty cool visualization of the growth of the Walmart corporation over time. Elegant and effective.
http://projects.flowingdata.com/walmart/

Thursday, July 10, 2008

20-70-10

Twenty-seventy-ten. I hope those numbers hold no special meaning to you. I occasionally see those numbers on white boards around the office and overhear them in conversations.

20-70-10 is a technique that some high level managers advocate for driving a high performance organization. It's part of the Jack Welch GE management system. In short, the system is set in place to differentiate and rank all employees and systematically remove the bottom ten percent of the group and generously reward the top twenty percent. The idea is that the best people in the organization will stick around and you drop the dead weight.

I've made a little chart depicting the theory. In the chart I have an organization that consists of people that I ranked by strength, 1-10 and also relative strength within the organization. For example, after the first iteration those employees with the bottom ten percentile of strength is 1 were removed from the pool and a set of new employees with a strength of the mean strength of the group, 5.5 is added. This is purely an abstract model of the system, however certain trends appear quickly. Within five years the weakest group are at the same strength that was at the middle of the pack at the beginning of the iterations.

There are also some other interesting projections in this model. Look at the top. It's virtually unaffected. The top 30% can stay there through the whole exercise without making any adjustments. The 60-69% can stay in that position without adjusting their strength for 5 years.
The strength of this system is that it does purge the weakest people from the system. There's no doubt about that.

What my model fails to capture is the forces at the top. The people in the top 20% are certainly motivated to compete to stay up there. Providing that kind of motivation though isn't cheap. If the carrot were to motivate the top 20% it will need to be substantial.

To offset some of that expense, the middle 70 and, even more, the bottom 10 will enjoy much less incentive than they may feel they deserve. Attrition becomes an issue, certainly those who are calibrated at the bottom are forced out, but there are others who will leave because they feel that they are not being fairly recognized for their contributions. Are these people so bad that by terminating them the organization is better off? How does a system like this deal with valuable people who are lazy?

Take the case of the person who comes in at 21. One person shy of the beautiful people. What is her reaction to this assessment? Did she contribute less than the top 20? How can she be certain that the calibration system is accurate or equitable? She really can't.

What are her options? Well, she can try harder and try to break into the top 20%, but isn't there another option? This isn't a closed system. There are other options outside of the organization. That has to be a consideration and a legitimate risk to lose excellent people.

A system like the 20-70-10 is good for cleaning house. It will clear out the weakest employees. This isn't necessarily a bad thing to purge the weakest people out of an organization when those people are considerably weaker than those who are brought in to replace them.

The hiring assumption of this model is that on an aggregate level only those who are as strong as the mean of the group are hired. This system raises the hiring standard on a logarithmic scale. Each subsequent year of the system raises the bar less and less.

I do not believe that a 20-70-10 system should be sustained for an extended period of time. Given ideal circumstances it starts to lose its value after a few iterations.

When you factor real world situations into the model it does not improve its sustainable effectiveness. Consider a situation where people within the organization are laid off. This happened in my own organization. About 25% or my colleagues were laid off for cost cutting. This happened independently of the 20-70-10 purging process. Those who were laid off were within the bottom 50% of the organization so when it came time to let the bottom 10 know who they are, we had people who were possibly in the lower third of the company at the start of the year ending up in the lowest 10 at the end.

Occurrences like the one outlined above undermines peoples senses of security. When people worry about termination and their ability to meet their needs, they aren't productive.

What organizations in the field are finding is a 20-70-10 system can add a great deal of value for a few iterations. It is excellent at creating a culture that does not tolerate underperformers, but if allowed to run unchecked the system loses its value after a few iterations.

Tuesday, July 8, 2008

Begging the question by giving questions

I try not to make it a secret that people usually don't use the phrase 'beg the question' correctly. Smart sounding people use it all the time, 'that begs the question that...'. For the record begging the question means that someone is assuming that the answer to a question has been provided.
The word beg in modern English usage almost exclusively means to ask for something or to plead. Nobody would confuse a beggar for someone who wildly assumes things.
This brings me to the point of my post, which is when one begs the question by providing a questionnaire. I believe that many answers to questions were begged, or assumed, by my company's management when they formed the questions of a company wide survey last year.
It was no secret that those of us in development roles did have a career path beyond our current roles.
It was no secret that we were calibrated in a closed door cabal like meeting, which was rumored to be more of bout of managerial influence than an objective discussion of the relative contributions of peers.
Managers did not provide much in the ways of career counseling or mentoring. We received feedback on how we were doing.
When a questionnaire was issued asking about these topics we, the employees, answered truthfully. To no surprise, we learned what we already knew.
As a result of our answers*, we found out that we would be working differently. Many initiatives were created to correct these deficiencies. A set of career paths were made by our HR department. Also, calibration was going to be more objective. Managers would take a more hands on role in helping to develop their reports. Training would become a priority. Many of the things that the company wasn't is what the company would become within the year.
To many of us it was a complete over-reaction. It's like how Lewis Black described airport security before and after 9/11. Before our attitude was we're not doing anything and then after 9/11 the attitude was we've got to do everything!!!! WARNING: Details of the overreaction ahead, skip to Monkeyshines to avoid griping.
To the affected, my peers, we learned that new roles were defined with swim lanes. We saw a path that could lead to at least one grade higher. As a developer I could be promoted to a senior developer position and enjoy the same pay grade as my manager. If we swam fast enough we could reach the pinnacle of the non-managerial IT positions with a senior director pay grade. Pretty sweet.
What we also learned was that our roles would be changed. A concept of a Center of Excellence would be the paradigm for our division. Our center of excellence focused on development. We were divorced from our previous projects, instead we were internal consultants who developed applications for different areas of the business.
Our peers, who took ownership of our former applications were to no longer develop applications. Their role was only to design applications and lead developers.
As part of the center of excellence for development, we'd establish and present standards and best practices in parallel with our other projects. Our projects and tasks in general were all paralleled, instead of having a few things to work on, we had many things. When a project ramped down, we were put on another project that was ramping up. When an employee was needed on a new project a contractor would be tasked with cleaning up the mess with the old project.
Monkeyshines:
Ok, I hope I've communicated that big changes were carried out for the sake of meeting the gaps that were reported in the survey. We knew that these measures were from the survey because the managers and HR people who presented these changes reminded us that they heard us loud and clear. Some of us even questioned whether they were trying to communicate that if we were to report any future shortcomings that another overcorrection would be forthcoming.
What was not asked, but what was later begged, is whether that system was so bad that we should scrap the whole thing. What wasn't asked, but what was later begged, is whether this 20/70/10 Jack Welch system, i.e., reward and remove; rank and yank; calibrate and eviscerate; praise and phase(out); pick and kick; salute and boot employees was such a good system after all these years.
It feels like the changes were a foregone conclusion and the questions were written to make us feel empowered after the fact.

Monday, July 7, 2008

From Lifehacker: Should Voicemail Die

Over at Lifehacker they pose an interesting question: Should Voicemail Die?
My vote is that the current system of managing voice mail through the phone should definitely go away ASAP.
The whole process of managing messages through a phone is incredibly slow. I speed up the process by writing down the series of buttons I need to push to get my, thankfully, occasional message.
Phone menus are terrible though. There is so little actual data throughput in comparison to other methods of communication.
I do like, in principle, how Comcast does the voice mail for their Digital Voice phone service. Messages can be accessed online.
When someone calls my home phone number and leaves a message I receive an immediate email. I copy the link and paste it in Internet Explorer, because I can never get the Quicktime plugin to work on Firefox, and then I listen to the voice message.
This slightly byzantine process is faster than going through the phone and it could be much easier if I put in the time to get that Quicktime plugin to work in Firefox.

Happy 4th of July

It's a little late to wish everyone a safe 4th of July weekend. One question that's been going around lately is where do you buy the best fireworks?
In my state, Minnesota, there are laws that restrict the types of fireworks that we can legally purchase. In our neighboring state, Wisconsin, the laws are less restrictive regarding fireworks, but they do have a limit. Many of us consider Wisconsonians to be a little crazy, Wisconsin Crazy.
I have friends who are not satisfied with the restrictions imposed by the state of Wisconsin regarding fireworks. They want to know the closest state is that has the least restrictive laws regarding fireworks. After a little research I believe the answer is Alabama.
Now we have a gauge for craziness, Wisconsin and Alabama. I suppose the next level is Mexico.

The mythical monkey month

Some colleagues questioned whether it would be fruitful to project plan based on an estimate of how many monkey months it would take for the project to complete.
If one were to assume that given a sufficiently large number of monkeys on a sufficiently large number of compilers it should only be a matter of time before one of them writes something that meets your requirements.

Thursday, July 3, 2008

Useful friends

Not to sound too Machiavellian but friendships can be useful in advancing one's interests.
In an office, there are many people whose friendships can be quite useful. I don't mean to condone to befriend people on false pretenses, but it never hurts to make certain that you are friendly with people who can help you.
If that is harsh, please consider this my list of people with whom you should especially avoid making enemies.
  1. Administrative staff(secretaries and assistants), you want to know who knows about an upcoming layoff or big contract, the administrators. They handle their managers documents, their emails, they plan their trips, they know almost as much as their managers. They may also carry some influence with their managers. You should never make an enemy out of an admin, and it doesn't hurt to chat with them from time to time.
  2. IT Administrators, same type of deal with the assistants. System administrators can really help you out if you are in a bind. Having a friend who can get your computer repaired or give you an off the record ETA on an issue is a big help.
  3. HR, you want to know what's going on in your company, make really good friends with HR. They know everything. If you get on their good side your life will be a lot easier than if you are in an adversarial relationship.
  4. Managers, even if they aren't yours you should be nice to managers. Consider them your safety valves. If your current situation isn't working out, they may be able to facilitate a transfer to their group.
  5. Outgoing people, don't think of someone's leaving the office as abandoning you. Think of it as opening a door to possible opportunities. There's no telling what's going to happen at your office. Your company may be acquired, the brass may decide to outsource the whole division to India, they may make working there unenjoyable. Having friends outside the company who can help you is a great asset.
Our culture has a negative perception of people who use others. It isn't necessarily a bad thing. Don't feel guilty for looking at how people can help you. If helping others is something that you enjoy doing, you probably look for opportunities that you can help others. When you ask people for help you give them the opportunity to feel good about helping you.

Today's Agenda: what is wrong with this picture

This is real from today, let's see if anyone can spot anything amiss with my agenda.
  1. address production issues from last night ~1 hour
  2. finish self assessment and send it off to my manager ~20 minutes
  3. transfer data from my individual performance scorecard from the excel template we used to the online version through PeopleSoft ~40 minutes
  4. update information in my individual performance scorecard ~30 minutes
  5. perform peer evaluation feedback for peers ~2 hours
  6. attend standards and best practices meeting for development technologies ~1 hour
  7. status meeting with offshore development team ~30 minutes
In the 6 hours of activities I have scheduled 1 hour was spent working on some errors from a nightly process--thanks other team that didn't care to check with us before messing with our resources. I have a 30 minute meeting discussing status, that's probably the only valuable and necessary activity in the day.
Self evaluation and performance management activities are not a total waste, but they aren't worth half a day either in my situation.
In my current position I meet with my manager in a 1on1 every week. We sit in adjacent cubes and chat every morning. We eat lunch together from time to time. We communicate. If there were something about my performance that were in need of correction, I'm sure I'd hear about it.
I understand the value of feedback. I enjoy hearing that I'm doing a good job and I appreciate hearing about things I need to improve as early as possible.
The current system we have is a reaction to the division's process for managing performance. My manager does not directly decide how to reward his reports for their performance. Typically managers get a budget to give their reports raises and the manager allocates those funds as he sees fit. In my company it isn't a person's manager who makes that decision, instead it is all the managers and above in the supply chain rank all of the people at each pay grade and award them raises and bonuses based on where they sit compared to their peers.
The system diminishes the role of the manager. A manager has a say in where her people are, but other managers need to agree. This system rewards people who are visible and perceived to be strong performers by as many managers as possible. A person who is perceived to be in the top 10% by many managers is going to be ranked higher than a person who is perceived to be in the top 1% by a single manager.
This system has another serious flaw as one of the stronger willed senior directors would take the position that her people were all in the highest tier, and should be rewarded the best, and that the other directors had the scraps. That wasn't an equitable system. It also wasn't a secret that this is what's happening.
To correct these perceptions of inequity, all employees are expected to spend about 4 hours a week performing tasks to monitor their performance. 10% of our time is spent performing non-productive tasks to manage our performance. That's a 10% reduction in a work force's ability to add value that is spent to create the perception that they are being rewarded equitably for their work. I would argue that the real cost is even greater. People don't enjoy tracking their performance. They'd rather spend the time performing and let the managers notice.
Joel Spolsky wrote an excellent essay denouncing the practice of incentive pay. The essay concludes that creating incentives to do your work is tantamount to creating a system of bribes. Incentive based pay will corrupt the motivations of the workforce and the net result will be an underperforming work force. If the net result of incentivizing your employees work is a less productive work force, does it make sense to cut their work week by 10%?
A point that Joel made is that regardless of how praising one's performance review is, that person will be disappointed by it. I can attest to that. I've received many formal performance reviews, most of them very good, only one that I can think of that wasn't so good, and directly after all of them I was disappointed. The not so good one because I felt that my manager had no idea what I was doing. In the good ones, I didn't think that they were good enough. They'd tell me I was doing a heck of a job and then bump my salary by about 4%. In hindsite it didn't seem so bad, but at the time it kind of hurt. I'd work very hard and the couldn't even throw me 5%.
At my current company I can't help but wonder where we'd be if someone stood up to that pushy director. We'd probably only have to spend a couple hours a week working on reporting our performance.

Wednesday, July 2, 2008

Today's Gripe: Drive by Tickets OR How can I give good service if you won't let me

I have a pet peeve that I call drive by tickets. I define them as a ticket or request that someone makes at the last moment before they become unavailable to talk about the ticket or request that they made.

My first reaction to a problem ticket or request is to communicate with the requester. Regardless of how much detail they put in the ticket I want to make sure that I get the full story before I work on it, especially if I need to make a change. I think that it is only responsible to make sure that I am on the same page with the requester before I service their request. I can't think of a time where following up with a requester has not provided value. To me, it's what providing service is about.

When people make a request and then go off to an all day meeting, go off-site for a seminar, or go on an extended vacation; my ability to service their request is reduced. I can only go on the information that they give me. Sometimes I have enough information to service their request, but usually there are some details that could help better service the request that are not communicated within the request.

When I need to take action to service a request without communicating with the requester based only on the information provided in their request, there is a greater chance that corrective action will need to be taken to correct the gap between the intent of the request and the product of the actions taken to service the request. At this point, the requester and I are probably having a meeting that contains our coming together to better understand the needs of the requester, but we're probably also going to discuss other things, like why did I screw it up.

This type of change is more expensive than it might appear.
Any support people who helped me service the original request probably will need to help me service the corrective request also. That is time that could be spent performing other tasks, like supporting changes that won't need to be corrected for other people.

Let's consider an alternative: I meet with the requester and understand their needs and communicate with them about how I can meet their needs. I learn more about what I can do, maybe I can influence their outlook. Maybe I can provide something that is more simple or that exceeds their original expectation. The net result is that the requester will probably be happy about the attention that their request receives. They will also be happier that their request is taken seriously. When their request is serviced they will be delighted by the experience.

Compare that experience with how the requester must feel when they make a request and the action doesn't exactly meet their needs. Their mood will not improve, instead it will deteriorate until the meeting with the managers is called where the requester discusses why their request was not satisfied. It's not going to be a very happy meeting. It should be the lowest emotional point for the stake holders. The actions taken from that point are more likely to actually satisfy the request and will likely improve the mood of the stakeholders. However the stress of the initial disappointment will spoil some of that joy.

I'm not a fan of having meetings for the sake of meetings, but something meetings actually can do good things.