The four-day work week
Igor and Johannes are now in their second week of experimentation with their new timetable, a four-day work week plus one day we’ve been calling an Input Day (Inspiration Day sounded just a tad too cheesy). I, on the other hand, already only work four days a week. While the other two keep track of how the Input Day is working for them and what they’re doing with it, I’m exploring ways to consolidate my reading/staying-informed-time, so that I don’t try to do it concurrently with other work. As Igor pointed out, this leads to guilt and less concentration on one or the other.
While a four-day week is enough to really get into something, I find that sometimes I’m lacking the “time” (it’s really the structure) to produce original material and ideas that don’t necessarily have to do with a specific project we’re working on, but that could streamline processes or add to what we can offer both to our clients and the digital community. In short, using my own initiative to make things work better. I’m currently favoring the idea of blocking off two hours for Output (working on projects and ideas like those I’ve just described), and two for Input (staying informed and reading up on current topics of interest), at favorable times during the week. The rest goes to client work and the regular blogposts/newsletters. We’ll see whether simply allotting the time works for me.
Continuing the train of thought on streamlining processes, I don’t know how many times I’ve been told this, or learnt it on my own, but I have to relearn it periodically: Thinking outside the box is great, but only when there is a box to begin with. Thinking outside a non-existent box is only confusing. Also, when thinking inside a box, it has to be a box that allows you to finish thinking, rather than one with a trap door leading into a never-ending vortex of recursion.
I identified last week that my biggest problem when it comes to finishing a task is establishing the level of detail to go into. I was reminded of learning the Distributive Property, or that x(y + z) can be expanded into x*y + x*z. Somehow I didn’t understand initially that this expansion stopped at some point, but thought instead that you just kept going.
9(5 + 3)
9*5 + 9*3
9*(2 + 3) + 9*(2 + 1)
9*2 + 9*3 + 9*2 + 9*1
9*(1 + 1) + 9*(2 + 1) + 9*(1 + 1) + 9*(1 + 0)
After all this, it no longer made any sense that one would want to use this handy feature of mathematics at all. This is the sort of convolution I can get myself into while working, if I don’t first establish boundaries before I get started on a task. For instance, I need to make a slide deck on X. X is made up of components Y and Z.
X = Y + Z
Looks easy enough — just have to do Y and Z and then I’m done. But as I’m working on Y, I realize that it too is made up of other things.
Y = U + V
=> X = U + V + Z
But then, of course, U is also made up of more things that I hadn’t thought about before, and so is V…
U = R + S; V = P + Q
=> X = R + S + P + Q + Z
Knowing all this, I look at Z there, all the way at the end. Big, scary, unknown Z. Who knows how many pieces that bit will turn out to be composed of? And all of these things still seem so important, even though they may or may not be…
Suddenly the job starts to look a little scary. But if I had set clearer boundaries, and said, for example, that I would break the task into 5 questions to answer, and have a maximum of two slides to answer each question, I would have prevented my problem. There needs to be an overall goal, and then a scope for every identifiable part of the task, so that it’s easy to tell when you’re done.
Once the box has been drawn and its boundaries identified in every dimension necessary (time, size, priority, etc.), then you can proceed to think. If you don’t do this, I’ve found, you can expect some hiccups, and when these occur, it saves a lot of time to remember that you can always go back to this Step 1.