Why you should (and shouldn’t) track time

It’s pretty much industry standard that, when we estimate the cost of a web project, we do so based on the amount of time it takes. If you’re a contractor you’ve got an hourly rate or a day rate. If you work in a shop, your company has one too. Is this the way we should value our work? Does the amount of time you spend consulting, designing, developing, debugging, and testing really equate to how much it’s worth?

When we talk about time tracking against a project, I think we (the industry, at large) often lump together two different metrics that simply should not be lumped together. I’d like to think of these two metrics differently:

• The value of the web application (and the value of the service you provide your customer to build said application)
• The time you spend building the application

These two metrics have very different end goals. Here’s how I’d like to think of them:

Value: How much should this project cost?

My goal has always been to increase the value of the service I provide the more experience I get in this business. I want someone to pay me more money the better I get at developing web apps. Take the most recent web project I worked on. If I were to build a similar project a year from now, I hope that I can provide even more value than I did this time.

When I provide more value, the cost of the project should go up. So, what makes up “value”? What is a client paying for?

Flexibility. If you’ve been in this business long enough, you’ve come to terms with the fact that most clients don’t know exactly what they want up-front. Be it features or font, clients need to see it on screen to start figuring out what’s working and what’s not. The more flexible you can be, the more you can work with not-fully defined features, the more you can build and let your client make decisions in the midst of development, the more value you’re providing. This is extraordinarily valuable to clients, especially those not so familiar with the medium.

Education. There’s a difference when a client works with WAM versus when they decide to off-shore a bunch of work to an anonymous, faceless company. Because, when we work with clients, we’re teaching them too. They learn about the nuances of the web (browsers, analytics, SEO, etc.) and about how we work (What’s a data model? What makes a user experience a good one?). At the end of a project, they understand the medium much more than when they started. That’s value too.

Personability. Everyone at WAM is expected to be personable, friendly on the phone, and write thoughtful, thorough, considerate, spell-checked messages to our clients. This is not an industry-wide standard. Making your clients feel good about the company they’ve hired — that’s worth something too.

Expertise. We’re the domain experts in web development. We drive the process in both how we work and the products we use. We have opinions. When clients come to us, they’re often looking for us to provide the answers and recommendations. We provide value by being unabashedly firm about our opinions.

Speed and timeliness. This is the kicker. We’re valuable because we’re FAST. Timelines constrict but the end dates don’t budge. This is invaluable, but it works in contradiction to the second metric.

Time: How long will this project take?

And all the while I’m trying to increase the value of the service we provide, I also want to decrease the time we spend on projects over time. We ought to be better, faster, and more efficient at doing the same job a year from now compared to today. And so, to me, time tracking should be a metric that tracks the internal health of the company and the individual contractor, not the value of the work. Time tracking answers these kinds of questions:

• Are we balancing the amount of work we’re doing as a group, and individually?
• Are there bottlenecks we can spot in our process that we need to fix?
• How much more can we take on while still maintaining the quality of our work?

The time we spend on a project shouldn’t necessarily correlate to the value of the project. In fact, they’re often in complete conflict with each other (e.g. some clients needed that work done yesterday). Time spent and value provided are two very different things.

But, when most companies and individuals estimate the cost of a new project, what do we end up doing? We estimate it off time. We make guesses about what might change, pad for uncertainties, multiply by our rates, and hope the final dollar feels right before we push it to the client. The end result is, we get these weird contortions of time estimates that get us to a cost we think feels just. There’s an unsatisfying arbitrariness to it all. It may just be because we are trying to combine two metrics that, at least in this industry, don’t really fit together well.

Time does not equal value, unless we decide it does.

At many companies, time tracking becomes your individual value to the business. They mask it behind the ridiculously named concept of “employee utilization.” The more hours you can bill to a client, the better utilized you are. Sadly, most companies do it this way.

But this completely discredits those moments, the ones that all of us programmers cherish, when, in the midst of development, we suddenly come upon a more elegant, clever solution to a problem. Those lightning-strike moments of genius. But, if, it suddenly means that my 8-hour estimate turns into 2-hours of real work, by golly, I’ve just cost myself (or my business) 75% of the value I thought I was providing. I’ve now got to fill those extra 6 hours with new client work, assuming it exists, lest my utilization numbers start tumbling down.

At companies like these, ones that look at programmer value as simply a scorecard of how many legitimate hours, seconds, and minutes were spent fixing a problem, rather than those other metrics that really equate to value, there’s no incentive to get better at your job. You’re far better off towing the line, working to fill in every hour you’ve been allotted, than trying to be more clever and creative about your work. At companies like these, many programmers trade in their natural intuition to do their work more efficiently so they can legitimately get their utilization numbers “up.”

Estimating and tracking time is important, but…

I’m not suggesting, at all, that estimating time for a project and then tracking it isn’t valuable. It absolutely is. It helps the individual and the company gauge how much work is enough work. How much more, or less, can we really handle? At the end of a project, it helps us figure out where we were better or worse at gauging this time, so we can be more accurate about these numbers on the next project. But, we must differentiate that exercise from how much a project is worth. They are two distinctly different metrics.

So, if not time, than how do we measure the price tag we should on a project and the services we provide for that project? How can we do so, other than deciding that a cost feels right — other than, perhaps, shifting the entire industry into a Wall Street-like marketplace, where the collective agrees that service X or product Y is worth this much today? I don’t have a complete answer yet.

I look forward to yours.