Embracing Change: Or How I Learned to Stop Worrying and Chuck My Daily Plans

First, some background. I’m working primarily on a time and materials project, focused on handling whatever problems may crop up that are currently high priority to our client contacts – either for the introduction of new features, fire-fighting or bug squashing. From time to time, something big enough will spontaneously combust, and I’ll be forced to drop everything I’m working on and run over and fight the fire that’s appeared.

Though this didn’t (and doesn’t) happen often, when it did happen, it would disrupt the mental plan I’d formulated for the day. So instead of going from A to B to C, now I was working on Fire D, and since I didn’t meet my expectations for the day, I felt unproductive. I used to get upset that I had to put my work on hold and work on something else. And just in case the bolds didn’t give it away, I’ve come to realize exactly how selfish and stupid I was to think that way.

It isn’t my time; for every moment I was working on my previous task, I was using the client’s time. I realized that my attitude was completely at odds with what I loved most about the project I was on – providing value and a service in the most direct means possible.

Over time I’ve gotten better and better about shifting from one task to another, and, though I doubt that I’ll ever be happy to receive one of these calls (due to the fact that this usually means something is broken, and it is still disruptive to be torn from one task to another too often), I’ve learned to take these switches in stride – knowing that what I’m about to do is going to save the users from some pain they’ve been feeling.

Lately, I’ve made a conscious effort to not formulate this kind of ad-hoc plan because the project priorities are constantly shifting from one side of the system to the other, and though this used to distract me, I’ve since learned that though the project may be being pulled in different directions, I don’t need to be pulled with it. No matter what I start to work on, I’ll be doing something of value for the users and the client.

Every feature that gets implemented and bug that gets squashed helps to provide value and ease pain. Every fire that gets put out in a timely manner is one less affected user, or one more piece of data that gets entered into the system correctly. So I’ve given up planning my work item priorities, and when I complete a work item, I do a quick triage (value over effort) of the issues at the top of the priorities queue, and act from there. And if at the end of the day, I’ve done more good for the client than I’ve eaten in budget, then that was a productive day.