Tag Archives: consulting

Blog

Maker, Manager and Consultant Schedule

Have you heard about the Maker Schedule? The idea resonated as it explained a lot about my productivity.

For the uninitiated, here are how the two types are defined.

The manager’s schedule is [where] each day [is] cut into one hour intervals. You can block off several hours for a single task if you need to, but by default you change what you’re doing every hour.

The Maker’s schedule, on the other hand:

[Makers] generally prefer to use time in units of half a day at least. You can’t write or program well in units of an hour. That’s barely enough time to get started.

The challenge I have is that I’m neither a maker nor a manager. As a “consultant”1 I fall somewhere between the two. The variety is what makes it interesting to me. The variety is also what makes it difficult.

Sometimes I have to sit and concentrate for a large block of time. Maybe I’m sketching out an architecture, researching something, building a prototype, or debugging some code. Perhaps I’m writing a report or putting together a presentation.

On other days I have back-to-back meetings. Workshops, delivering presentations or training, and explaining the results of my research.

But the worst are days where I have an hour’s meeting followed by an hour “gap,” repeated. Technically, I’m only in meetings for half the time, but it wipes out the whole day in terms of productivity. I spend half the day either context switching or with a tranche of time that’s too small to do much useful. A few days of these meetings and I feel very busy but not very productive.

The internet is full of suggestions on how to manage your schedule correctly. Few of them work for me.

A popular suggestion is to schedule meetings together, always in the morning or late in the day, for example. But what if I have clients in India and colleagues in the US? (I do.) There can be meetings at any time, and timezones mean that I can’t reasonably move them. I do have a certain amount of latitude in terms of moving some meetings around, but there are constraints beyond my productivity. If I (an individual) am trying to set up a workshop with half-a-dozen people and they’re paying for the privilege of meeting me, I’m at a disadvantage, schedule-wise.

Another suggestion is to block out the time in my calendar. This is probably the most effective method, but it’s not without its challenges. It’s hard to ‘hold the line’ against people booking meetings. Whether it’s someone not knowing how to check your calendar (or them not caring), frequently pushing back when you have no other firm commitments can look like you’re not a “team player.”

Another reason it’s hard to keep those time blocks is that it can be hard to know how long they need to be. Consultants usually have to maximise “billable time,” which makes it hard to turn down sure-fire client-facing hours. If I block out four hours in my diary, what’s to say I won’t get stuck after an hour and have to wait for feedback? What do I then do with the remaining three hours? It’s a real optimisation and opportunity cost problem.

So what’s the answer? I wish I had the One True Way. I’m not sure that one exists. Unlike many of the other people giving advice on the internet2, I am not 100% in control of my schedule. The best I’ve been able to come up with is a combination of all of the above. I try to have meeting-free days. I try to block time where it makes sense.

To an extent, it’s my job to be flexible and available for clients. Maybe I just need to learn to live with it?

  1. I’m a “field engineer”, which means I help clients get the most out of my company’s software. ↩︎
  2. As ever, you get what you pay for. ↩︎
Blog

Real World Problems

I think it’s fair to say that a lot of people who know me In Real Life have no idea what my job is. Most think I sit in front of a computer all day, programming. That’s not really true. Well, I sit in front of a computer but I actually spend surprisingly little time actually writing code.

There are lot of ways to explain what I do, but many quickly get too technical for most people. At a high level, I’m a client-facing engineer. Most often, I sit between engineering — the people who do spend all day coding — and the end users of the product.

As I explain at job interviews, I like to solve useful problems. And being close to customers, the real end users of what products are for, I get to see both the pain and the joy when some gnarly problem is solved well. Sure, there’s an intellectual buzz when you fix or make something abstract but I find there’s something extra when I solve a real world problem.

Another aspect that I like, is that I get to see how the money is made. What I do has a direct impact. If I’m billable, every hour I spend working for a client is both helping the client and making my company money. If I’m doing pre-sales, when they sign on the dotted-line the same thing happens.

I say this not because it’s absolutely necessary to have the relationship that clear, but I do think it’s important to understand the impact you’re having.

For example, here’s a quote from an article I read earlier today:

There are certain things you do not in good conscience do to humans. To data, you can do whatever you like.

Maybe this is inevitable when you get to Facebook’s scale, but by losing track of what the company provides to end users, by losing sight of what you’re doing, much is lost. You don’t see what value you’re bringing any more; it’s all too abstract. And, by extension, you fail to see the harm that you’re potentially causing.

I’m not saying that by having to look a client in the eye you’re always going to be 100% ethical (some people don’t care either way) but I like the obviousness of the connection. I don’t have to theorise about how the product might be used as I can see it right in front of me, I’m helping people actually make it happen.

So, if you don’t know what I do, you probably still don’t have a significantly clearer idea. But you might better understand why I do it.