Remember Your Worth

Skating is what you do, not who you are.

My favorite DCOM, and I hope yours as well, is Brink. This quote, which comes at a boring, sappy point in the movie in between the awesome action scenes of hardcore inline skating madness, has always stuck with me. What follows is a great explanation of not falling into the believe that what you do defines who you are.

It’s by no means a perfect analogy, but I do think it is an apt one. Even if that work occupies nearly every moment of your waking life, even if you love, living, breathing, sleeping, and being completely immersed in the work, you do not equal it. There is no equivalency (you != work, for the technical), there is no summation over the domain, there is no amount of arithmetic or logic that can equate you the person to the list of tasks, projects, and responsibilities that you the person create and have control over.

You do work, but you are not defined by it.

That’s an important distinction, and one I think is lost on a lot of men and women my age that have just begun their careers in the knowledge worker industry. It’s certainly something I’ve fallen prey to, if I’m not careful about my work.

Because it’s so easy to get sucked into. It’s so easy to open up Outlook and start “handling” email – responding to questions that come in, sending off questions of your own, replying, forwarding, cc’ing, flagging as important.

Or maybe instead that cyclone of focus is Excel, whipping up spreadsheets like it’s nobody’s business. Hardcore spreadsheet mode, marking up cells in all sorts of meaningful color, writing up formulas that would take a Rosetta Stone to decipher, pivot tables, Gantt charts, and all manner of project management tools squeezed into the workflow of an accounting and tabulating application.

I’ve seen this happen to developers, too – have it happen to me as a developer. Working off a bug list, squashing, stomping, eliminating left and right. Or working off a requested features list, implementing, implementing, implementing, every widget and bubble deemed important enough by a user to write a hastily and poorly spell-checked and formatted email coded up and shipped.

Work like this is comforting. It’s easy. There’s very little in the way of thinking, very little that needs to be thought about; it’s all do, do, do. There’s a satisfying rhythm to it, getting yourself into the checklist mentality of completing the items off of a list. There’s a visceral pleasure to making a list of everything and crossing out each item s they are assassinated with elbow grease over the course of the day.

The trap that we inevitably stumble over, fall down, and tumble into the dark, gaping maw of is that we let the “what” of our work define the “why” of it. Our projects successively morph from “successfully implement foo” to “respond to email about foo” to “catch up with all this email.” Soon enough, you are the loud guy in the hotel lobby pounding away on his blackberry keyboard and yammering on his Bluetooth headset about how great he is at email.

Maybe you’d argue that this is just an imprecision of language; when we discuss our need to reply to email, our implication is that it’s in service of the projects and priorities that we own, manage, and concern ourselves with. But an imprecision of language, I’d argue, implies an imprecision of thought; if the distinction is not made in behavior, it stands little chance of remaining distinct in the mind.

Email, Excel, code – they are what you do, not who you are. It’s an obvious point, but I belabor it because while we recognize that these tools define us, we often fail to realize that they’ve come to define our work.

You are not an email out, email in machine. It isn’t your job to respond to email; if it were, you’d be working in a help desk somewhere wondering when they will build a machine that is smart enough to replace you. Email is a tool to communicate in service of accomplishing the actions and projects you care about.

You are not a spreadsheet machine. It is not your job to spend countless hours making a spreadsheet working and looking phenomenal. Spreadsheets are a tool that you use to display and manipulate information to complete thee actions and projects you care about.

You are not a debug machine, not a feature-implementing machine. It is not your job to fix every bug and implement every feature your users report. Code is a tool that you use. Your job is to use your best judgement to decide which bugs to fix and features to implement with the time and attention and energy that you have available at your disposal.

We need to resist the temptation of elevating the work we do with our tools to the same status as the work itself. To do otherwise is to risk losing site of the real work, of the important work, the hard work of doing and being better, rather than the easy work of completing a set of items from a list.