failure

If you set them up to fail

Blog

A long while ago, where "long while" is defined in Internet terms, thank you very much, I had a rough spot with a particular client. Kris didn't really like the client, having heard a lot of my war stories from the client, and encouraged me often to just quit the client. The work the client was doing was important to me, and I really liked, on a personal level, a couple people on the client's team. Quitting wasn't really an option, because it left the client in a rough place. Though I did manage to train someone else for the job, and left, the whole project made me feel like a failure.

From an objective perspective, I know the project didn't fail. It continues to save the company about $100,000 a year, many years out, which was a 4x return on investment the first year alone. The feelings of failure on the project, however, linger, even though I know, on some level, that I did as well as I could have given the constraints.

One of those constraints being along the lines of setting me up to fail.

Some tasks given are just not possible to do. Cost, quality or speed, the saying goes, pick two. Without the proper experience in setting expectations, or even the correct experience to know what expectations to set, just knowing that you've been set up to fail can be impossible. Having to create a new system, that integrates perfectly with an old system, never taking the old system offline, having to test with live data without causing any data corruption, having all the bells and whistles and new fads the client had just heard about, all with an aggressive schedule is god-awful hard, people.

I know they didn't understand how much effort I exerted with the project, because they figured they could replace the system with a rewrite in two months. Two years later, they're still only two months away from being done. Two months. I mean, really, how hard can it be?

Right.

So, listening to some other war stories today and yesterday, I can't help but think, wow, someone is seriously being set up to fail in these companies.

You can't hire a junior developer, then be surprised when she makes junior developer mistakes.

You can't hire a junior developer and not train him, then expect him to know the proper way to work with a revision control system, to know how to debug a program, to meet good coding standards, or not to break the build.

You can't set someone up to fail, then be surprised when they do. Doesn't work that way. When you set someone up to fail, you're responsible for that failure.

If only I had recognized that years ago, I would have saved myself a lot of heartache (but, well, that's true of a lot of statements, eh?).