I think of work as a fluid stream. It needs significant throttling sometimes (think "fire hose v. faucet"), but it comes, gets done, and goes. Simple, right? But what work does one do? How do you possibly make the call -- first-in/first-out ("FIFO") all the time? And is it just a matter of prioritization, or is there a deeper layer at which to analyze? This is where I've had to structure my thinking a bit, albeit with a little help.
GTD
I subscribe to most of David Allen's Getting Things Done ("GTD"), a framework for instantly classifying all work (particularly "knowledge work" like I do), dealing with unplanned work in the process of doing your scheduled work, and keeping track of deferred and delegated work. Many people try to summarize that using analogies, but I think the terms speak for themselves. Now, his practices are a hard pill to swallow at times, but the framework is pretty flexible, and it's what I use to get everything out the door, from bills to follow-ups, to projects, to client support requests.
It's really kind of handy. And dangerous. You can assume that everything is unplanned work and just be reactive. Or focus on your scheduled work and pay no attention to your inbox. If you have people relying on that or any other medium to connect with you, it's potentially bad news. So that balance, the activity of seeing everything in context and individually -- like I do with the Things app -- is kind of important. Those are the most important minutes of my day.
The Value Chain
I recently made the decision to fire a client for mismanagement. In some ways, this was a destructive act. I ended a revenue stream, ceased ties with a partner with whom I was actively developing products, and ended my sole relationship within a very profitable, niche vertical. And we were friendly to start with, though that cooled -- still, we had untapped potential. It was time to channel Michael Porter.
The Porter Value Chain in this case was broken -- I was sucked into intraoffice drama, the client needed a lot of hand-holding for testing and, ultimately, the person who took over the troubled project had never read the discovery document or learned what the product really did. Aside from, you know, computer stuff. This meant starting over, analyzing every assumption, and potentially (read: probably) some rework. *Every* part of that business got more expensive. If we were a lesser firm, I would make that an accounting problem. But really it's about opportunity cost -- the more backwards we had to traverse, the more skewed our overall schedule became.
Slow Growth Means Better Scheduling
I think one of the most important things, and something I'm trying to get better at, is scheduling. I try to limit myself to one of two meetings a day, only leave my office for meetings on Tuesdays, and reserve two days a week to be meeting-less. If that rule tree seems restrictive, you don't want to see what my calendar becomes *without* those rules. Fending Group is pretty well established now, and I don't need to personally pound the pavement and do free consulting sessions just to get work.
That said, we grew a lot faster in the first six months than I thought we would in two years. I'm also doing less development than I thought I would, though that's coming into balance. The important thing I've uncovered is limiting the number of concurrent projects. The devil on the shoulder will *always* say, "Well, hey! That's great timing... we should be done with that other project the folllowing week. Easy!" In reality, the last couple of weeks of active dev on any project is the all-hands period, followed by trainup, revisions, and release management. Listening to the fellow on the other shoulder: Always plan a full week in between engagements. It's way easier on the constitution. Does this slow growth? Yes, probably. But that's healthy, and ensures that the work your teams do, particularly at the all-important "bookends" of a project, is strong.
After all, nobody wants to drink from a firehose.
Post new comment