It’s three thirty in the morning.
I can’t sleep. My brain is firing on all cylinders. First, I had an idea for an article I am in the midst of writing. I couldn’t stop thinking about it, and paragraphs were streaming through my mind, fully formed. So I wrote them down. Then I tried to go back to sleep. But I couldn’t. My mind had moved on to a speaking engagement I’m doing next month. Again, text, fully formed, poured out. So I wrote that down, too. I did all of this from bed, by the way. With my iPhone. Each time because I thought what was happening was just a momentary flash of insight, after which I’d of course drift gently back to sleep. Wrong. Instead, I moved on to mind-writing another thing.
Not exactly great timing, as far as I am concerned, but my body clearly felt otherwise. Writing is supposed to happen after I’ve prepared an outline; when I’ve scheduled time for it; when I’m upright, at my desk; when the sun is shining, dammit. But for some reason, now is the time my brain has chosen for me to do this work. Which brings me here, to my desk, in the dark, where I’ve given in to my very awake brain. No one ever said great timing had anything to do with convenience!
Timing is something I’ve been thinking about since I read Doug Rushkoff’s book, Present Shock, which is about — among other things — the disorienting power of technology, particularly on our perception of time and timing. Doug has been all over the airwaves talking about this latest book, but a particular interview he did for an episode of To The Best of Our Knowledge really caught my attention. Midway through the segment, he said:
“The Greeks…had two different words for time. There’s the typical one, chronos, which means time of the clock — like, it’s 4:01 — and they had this other word, kairos, which meant timing. And timing was more about your readiness, or appropriateness. Timing was what only humans could really understand. It’s like, you know, I crashed the car at 4:01. But what’s the best time to tell Dad that I crashed the car? Is it 5:01? No! It’s timing. That’s after he’s had his drink and before he’s opened the bills. It’s much more subtle.”
This sent my brain in all kinds of directions. But I was listening in my car. So I “rewound” the segment on my iPhone and listened again. I was hoping to memorize what Doug said — a hard thing to do while committing the other half of the brain to watching the road. As soon as I got home, I listened a third time and transcribed Doug’s words. (Time and timing — notice a theme here?) Since then, the quote has sat in a writing ideas document I keep on my desktop. I’ve referred to it many times in conversation, and I can’t count the ways it relates to what we do here at Newfangled. But until now, I haven’t had quite the right application for it to share. So here’s a big one that fits right in with the time/timing dilemma I find myself in right now, in the wee hours of the morning…
Time and Timing for Web Projects
When is a good time to start talking with a web developer? Is it once you’ve got a clear direction for what you want to do, made a plan and set a budget? Or is it when you’ve got a vague idea, no set timeline and no idea what it might cost? You might think I’m leading you toward the former — toward a front-loaded, plan-first-and-bother-the-developer-later approach. On the contrary, I think the best time is when things are still unformed and messy.
In other words, let’s talk when you think you might want to jump, not after you’ve already decided to jump.
Typically, people think that before they call us, they need to have worked out every detail — that working with a developer means placing an order and being quite specific about it. In most cases, this is done with the best of intentions. After all, you wouldn’t want to waste a professional’s time while you hem and haw over ideas and options, right? No, they’ve got work to do! So you’re going to think through everything very carefully on your own, organize it all, then deliver it in a neat little spec sheet. The developer will be very impressed by this, of course, pat you on the back for your proactivity, and reward you with a great price and quick turnaround.
Except that’s all wrong. It never happens that way, at least not all the way through.
Instead, a developer will review that spec and ask a ton of questions. Those questions will reveal the holes, assumptions, and even not-so-great ideas that form the basis of the plan so far. Then, you’re back to the drawing board. You were trying not to waste the developer’s time; instead you’ve wasted yours. It’s not that developers want to be uncooperative, though. It’s quite the opposite: developers want to collaborate, which is always more efficient the earlier that collaboration begins. They want to start when you start.
To use Doug’s words, the kairos of web development is far more important than the chronos. Readiness is a matter of inclination, of knowing you have a need but perhaps not much more than that. Chronos — the specific sequence of things — is a plan that can only be put in place once everyone who has some expertise to contribute has discussed all the details, shared ideas, weighed options, and made decisions based upon what is practical and available. Once you think of it that way, it naturally turns your intuitions upside down. You go from thinking that you need to work out specifics before you’re ready to call the developer, to realizing that you can’t really know those specifics without the developer’s input. Readiness is what matters.
If you’ve acknowledged that you need a developer’s help to create something, then it’s just a short, logical step to realizing that you probably also need their help figuring out just what should be built, and how, and when. The product, of course, is the manifestation of the process. And the process is where the expertise is applied. It’s not sitting on a shelf somewhere, waiting for your order form to retrieve it. It’s a person, who is waiting to help you make something, when you are ready. Outcomes, not objects.
So, come to us with kairos, and we’ll give you chronos.