I hope this is not my legacy

What I would like, when starting a software project in a sizable organization, is a chess timer.

Every time I ceased to be able to progress with the project, because a detail needs to be clarified, because some decision needs to be made, or because it is waiting on a sign off, I would click off the chess clock. And relax…

I am a hopeless optimist, and fiercely competitive. This results in one thing when it comes to software development- I cannot predict how long things will take, within even 50%, maybe worse. When I start a project, it’s generally “about a week” from completion for the entire 6 month duration. And as far as I’m concerned that is absolutely fine.

What I don’t need is plenty of time to get things done, what I *want* is a ticking clock that I can see all day measuring my performance. The thing is I don’t want to be judged based on, is other people’s priority lists. Just because Bill in accounts is too busy to sign my project off, well, I don’t care.

If developers are to be treated as delivery agents or micro project managers- by looking at the absolute time to project completion, then you are losing all their efficiency. They stop worrying about how lambda functions can help and best practices they could be learning and that git command you only ever use once in your life, and start worrying about why Mike is chatting to Kat rather than emailing them back. Give them that clock, and ‘click’, they can switch to some other project safe in the knowledge that they are not being measured.

According to modern software management opinions, putting developers under pressure does not make them more efficient, and I agree with this. In my experience the negative pressure which is experienced is usually due to events outside the control of the developer- eternal delays, changed specs, pointless meetings, rather than because I screwed up and took too long doing something. If that is the case, my pride as an engineer trying to create a quality product will mean I work twice as hard to finish on time. As a manager I think you need a way to get your developers to feel competitive about their own performance, let them put their effort into creating quality, and let you worry about these other events and pressures. That to me is the role of a manager, and the chess timer fits this perfectly- you are giving the developer the chance to be responsible solely for the things within their control.

The other thing the timer provides, is an accurate way of tracking how long you spend blocked on projects. I don’t think it matters too much how long developers take to write a quality piece software (within reason), because you are getting some increased quality or feature for every hour they work (provided of course that what they are working on is well managed!). However for time projects are blocked, you get nothing at all.

One could argue that if you don’t care about time to completion, and developers can effectively switch between projects then there is no problem here, since your efficiency is still optimal. However we all know that business *does* care about time to completion- it’s just the developers who shouldn’t and/or don’t. The point here isn’t to minimize blocked time, although that is obviously a goal, but that it is properly tracked by the chess timer, so we can see exactly what proportion of a task or project’s total duration it took up. This isn’t something I have seen in my (limited) experience, but am interested to know if other companies do track.