In Defense of Differentiation

Cory Foy has posted on JoS that his company is moving to a system of forced ranking, where each employee is classified as an A, B or C performer.  (Aside:  This practice is known as Differentiation and was famously used by Jack Welch during his tenure as the CEO of GE.  Differentiation was most recently discussed in Welch’s book Winning.  Note that I am not an Amazon affiliate and make no money if you click that link, but I will say that I liked the book and encourage you to check it out.).  Cory is curious if such a system has ever worked out well.  The comments that follow Cory’s post skew against forced ranking, more commonly known as Differentiation.  This is no surprise, as most employees are unaware of one very important fact:

Your company is already ranking people, whether you know it or not.

Let’s be real here – is there a manager alive who can’t tell you who his star performers are?  Is there a manager alive who can’t tell you who his problem employees are?  Of course not.  Once you have those two data points, deriving the third (average performers) is a snap.  Is there anybody who really, truly believes that management treats every employee the same way?

Speaking for myself, if management is already differentiating employees into groups based on performance, I’d much prefer to have it be a codified, publicly-revealed policy than have it be a behind-closed-doors affair.  When it’s all out on the table, the employee at least has a chance to know where he stands and to find out how he can improve (or at least maintain) his performance.

In order to make differentiation work, you can’t just rank employees and let that be that.  You need to a) make sure every employee knows where he stands, b) set crystal-clear, measurable and attainable performance benchmarks and c) provide sufficient resources and coaching to give every employee a chance to hit his marks.  If you simply rank your people and then later punish them based on their ranking, you have just engaged in “gotcha!” management, and I have no respect for that.  But if you come up with good metrics, rank your people, and provide the feedback and guidance needed to let an individual work his way out of the Cs and into the Bs, or let a falling A correct himself to remain an A, you’ve done everyone a good turn.

Think about it.  If you differentiate with clear metrics and sufficient resources, when it is time to fire someone there are no surprises.  The employee is not living with an inflated estimation of his performance.  The manager has actual data to back up his decision.  The employee, presumably receiving feedback the whole time, will be aware that his performance has either been sinking or not making the cut, and will have had an opportunity to psychologically prepare himself, maybe even polish up his resume before the axe falls.  It is, in short, a much more humane experience than most firings.  An anonymous reply to Cory’s post reads:

Well, that sounds awful.  So basically it removes all incentives to help your coworkers?  So instead of helping someone when they have a question, you just blow them off because helping them out might bump you down a ranking?

In any well-thought-out system, helping your fellow co-worker should increase your ranking, not hurt it.  We’re not talking about Lord of the Flies here.

Case in point:  almost 3 years ago, I was laid off from a job.  It was a good job – I had interesting work to do, I was being paid well, I liked my co-workers.  It wasn’t perfect – no job ever is – but it was good.  At every feedback encounter, I was told that I was a high performer.  So far, so good.  So imagine my surprise when, in the second of three layoff rounds, I received a pinkslip along with several co-workers whom I had heard spoken of as not-so-good performers.  I was shocked.  A thought came to mind:  maybe I wasn’t really a top performer.  Maybe I’d been having smoke blown up my backside.  Either way, I had no way to know that I was even a candidate for layoff.  And of course, no company will tell you why they axed you after the fact, so to this day I have to wonder.  I’ve heard scuttlebutt that it was purely about salary, as the company was allegedly bleeding cash, but I’ll really never know, because that company did not practice a policy of open communication with employees regarding where the employee stood.  If there was anything I could have adjusted performance-wise to avoid being sacked, I never knew it.  If there was nothing I could have done to avoid being sacked, I never knew that either.  Does this sound like a humane way to handle such matters?  What makes this even more astounding is that the company built enterprise tools to help Fortune 500s manage the performance of their employees.  Oddly enough, these tools were not used in-house – we didn’t eat our own dog food.  If our own products had been used in-house, a number of people might have been a lot less surprised to be laid off.

To this day, when clients complain about employees not doing what they should be doing, I encourage them to make their performance expectations completely clear, because the sad fact is that employees often get in trouble for things that they did not know they were responsible for.  This is patently unfair.  I have even helped clients to create customized tools that help management and employee alike set goals reasonable goals together and come up with plans to achieve them.  It only seems right.

Given a choice between “gotcha!” management or properly practiced open differentiation, I’ll take a numeric ranking and a performance plan 100 times out of 100.

Wouldn’t you?

Andy Budd’s 10 Bad Project Warning Signs

Andy Budd really gets it.

Andy recently wrote a brief article entitled 10 Bad Project Warning Signs, and it is spot-on.  Reading the article, I felt as though Andy had opened his mouth and my words came out – I identified with his article that strongly.  I feel that Andy’s piece makes an excellent prequel to my own article about the 11 Clients You Need to Fire Right Now.  Follow Andy’s advice and you’ll avoid these kind of clients altogether.

Alright, enough gushing – let me quote the 10 top-level points of Andy’s article.  You can read it yourself to get the finer details.

1. The project needs to be done in an incredibly short space of time, due to a fixed deadline.

2. The potential client says that they have no idea about budget.

3. The potential client says they have a budget but won’t tell you what it is.

4. The client says they want the site to be as cheap as possible, or they have an extremely low budget.

5. The client expects much more from the project than their budget will allow.

6. You are expected to come up with design ideas for the pitch.

7. The potential client won’t tell you how many agencies they have contacted about this project.

8. You will be pitching against a large number of other agencies.

9. There is no central point of contact.

10. The potential client hasn’t provided you with a request for proposal and doesn’t have the time to fill in your design questionnaire fully.

I agree that these are HUGE problems.  Andy goes into more detail on exactly why these are problems in his article.  I don’t want to quote the whole thing here and spoil it, because you really should read it.  It’s obvious to me that Andy is a fellow grizzled veteran of the game, and he’s seen the myriad ways that clients – intentionally or not – sometimes make themselves virtually impossible to help.

I remember a recent client who was a combination of “tight deadline” and “no budget.” They wanted to do an extremely significant web project and have it launch within 2 weeks of our initial meeting.  Their total budget was tiny.  Both the deadline was the budget were a complete mis-match with the scope of the project.  Although I warned them that the project was high-risk and would require certain compromises in order to meet their budget and time constraints, and although they agreed that the compromises were OK so long as we could go back later and tune things up, in the end nobody came out happy.

Despite having agreed to the initial compromises, the client expressed disillusionment and bailed out of the “tune things up” phase of the project.  I was unhappy that they had bailed out on me on account of things that they had agreed to.  It was a great big mess, and one that could have been avoided if I had said “no” to the project.  The aftermath is bad for both of us: they’ll probably badmouth me despite my best efforts, and I’ll never trust that client or any business associated with them ever again.  Because I agreed to a project that was obviously ridiculous, we both lost.

Given the client’s grossly mis-matched budget, schedule, and expectations, that project had little chance of making it, and I suspected as much from the get-go.  Why did I accept it anyway?  Because the client agreed to significant compromises that brought the scope within what could be done for the time and money.  I had no idea that they’d suddenly go back on that, but frankly, after 12 years in the business, I should have been better able to identify this as a bad risk and move on.

Don’t make similar mistakes!  Give Andy’s item a good read, and have the courage to say “no” when a risky proposition comes your way.

Project Aardvark Revealed

Project Aardvark is a relatively novel publicity stunt organized by Joel Spolsky, the current grand master of small ISV publicity techniques.  The idea is to have a team of interns churn out a whole product over the summer, all while being filmed for a documentary.

From Yaron’s latest Project Aardvark blog post:

On the name front we had a meeting today and decided on the final name.  It’s all registered and a preliminary site is even uploaded.   Good luck finding it 😛

Much ado has been made about dropping hints as to what Project Aardvark does and how secret it is, but come on.  It’s a registered domain on a public webserver.  It’s not going to stay secret very long if you taunt people like that.  Eventually, some inquisitive soul is going to go looking.

In this case, the inquisitive soul is me.

I present the “secret” product of Project Aardvark:
From the site:

SidePilot allows people to help their friends, relatives, and customers fix their computer problems by temporarily controlling their computers via the Internet. It costs $9.95 for a day pass, or you can try it for free for five minutes

In short, it appears to be a competitor to

There you have it, folks – the big secret revealed.  And being the savvy marketer he is, I’m sure Joel is pleased as punch that someone took the bait and went looking for it, because now all the buzz-y conversations will start.

You’re welcome, Joel.  :p

Unavailable = Effective?

I’ve told you once, and I will tell you 1,000 times more in my career:  if you are not 100% unavailable for at least 2 hours a day, you probably aren’t getting much done that’s of any importance.

Although I not-so-famously disagreed with Jason Fried on the issue of functional specifications, I find myself 100% in agreement with Jason’s position on spending time alone.  Jason’s recent post demonstrates a solid understanding of what it takes to be effective and productive:

Getting in the zone takes time which is why interruption is your enemy. It’s like REM sleep – you don’t just go to REM sleep, you go to sleep first and you make you way towards REM. Any interruptions force you to start over. REM is where the real sleep magic happens. The alone time zone is where the real productivity happens.

I couldn’t have said it better myself.  But Jason takes it one step further than even I did:

So, what do you do if you aren’t 8 time zones apart and forced into alone time? You require it. Set up a rule at work: make half of the day alone time. From 10am-2pm, no one can talk to one another (except during lunch). Or make the first half of the day alone. Or the last half. But make sure to make the alone time zone contiguous – interruptions kill productivity.

Wow.  Half the day!  It seems excessive, but I like it.

We live in a grossly over-connected world, and I am convinced that the communication overhead we all have to put up with makes our professional efforts feel like running a marathon while knee-high in molasses.  I don’t think anyone can challenge Jason’s’ assertion that developers are most productive when nobody else is around – in fact, this stands for most jobs in most industries.

As usual, I can hear all you would-be artiste types getting ready to use this as a justification for refusing to communicate with anyone, ever but bear in mind that before you can set up a no-interruption schedule, you have to actually talk to customers, co-workers and managers alike to figure out what it is you’re supposed to be building.  And yes, that might include writing a functional spec.  Deal with it.  😉

But in general, yes – be less available.  Be more defensive of your time.  Be as in control of how your time is spent as you possibly can.  Your clients may whine at first, but once they see the results, they’ll thank you.

Interesting Responses To “11 Clients” Article


I seem to have stuck a chord with some folks – both good and bad – with my article about 11 Clients You Need To Fire Right Now.  I’ve gotten more feedback on this piece than on anything else I’ve written to date.

From my eMail:

“Don’t expect to stay in business for very long with that attitude.”

“Without burning bridges, you just enumerated a series of client archetypes that we have all worked with.  Great job!”

“You can’t just fire a client if you are under contract to complete a job for them.  I hope you get sued for breach, you smug ass.”

“I’ve always been afraid to stand up for myself against abusive customers, for fear of losing a contract.  But if you can do it, maybe I can too.  Thanks for talking about this!”

“You are now #1 on my list of vendors I will never work with.”

From my discussion forum:

Fletch writes, “I can think of a great topic for an article called “The One Software Developer Who Should Be Fired Right Now.”

John Borkowski writes, “Every one of the clients listed in the article will cost you money– at best by wasting your time, at worst by not paying at all.  If anyone honestly wants to serve clients like that, I have about 30 referrals for you.”

Gary writes, “If a vendor broke a contract with me because he didn’t like the payment schedule or because he decided I wasn’t a big enough fish, I’d see to it that vendor never worked in my industry again. Period.”

Around the blogosphere:

Eric Wise writes, “I couldn’t agree more.  It always amazes me when clients consistently pay late knowing that my company has employees and subcontractors that I’m responsible for.  I often wonder how they would feel if mysteriously their next paycheck was a month late.  Generally though I don’t consider this a client firing event unless the lateness is extreme.”

Kevin Dangoor writes, “I think everyone who has been doing software for a while has worked with some suboptimal clients.”

Joey deVilla writes, “I’m certain that Hawkins is speaking from real-world experience; I’ve seen a number of these client types from my consulting days and from horror stories told around the bar at developer gatherings.”

Overall, traffic has spiked by 100% in the past two days.  It seems as though the other consulting pros of the world have felt the same pain I have with regard to abusive clients.  Of course, the bad ones serve to help me remember to appreciate the good ones.

A word about breach of contract, which seems to be a relatively common concern when discussions of firing a client come up:  don’t you all write termination clauses into your contracts?  The client might decide they don’t like you, either, and want a way out of the contract.  Nobody wants to get up every morning and either work on or pay for a contract he is unhappy with.

In general, my company has a policy that either party to a contract can cancel for any reason with 10 days notice.  Work to date must be paid for in full, of course, but if a client isn’t happy with our service there’s no way I’d try to strong-arm them into staying.  And it works going the other way as well.

Is my company the only one that does this?