R-E-S-P-E-C-T

In My “Working” Day, I described an office with an “interrupt-driven” culture. And in the comments, someone (probably from the same office) asked:

Do you really think there’s anyone in our office that doesn’t view you, your time and your privacy with the utmost respect?

This is an important point. Of course the people I choose as my colleagues view my time with respect. Naturally. But interruptions can still cause a disconnect even when people consider your time a precious commodity.

They aren’t interrupting me because they think my time is worthless. They’re interrupting me because with the information they have at the moment, a conversation with me is the most valuable activity the two of us can conduct for the company.

That isn’t so odd. They have a different set of information in front of them, so while I look at the situation and think: The best use of my time is making sure that deliverable X is complete in this iteration, they look at the situation and think: The best use of Reg’s time is giving me a status update on deliverable X right now, so I can provide top-notch customer service when I call the client in five minutes.

Am I right overall? Are they right overall? What is the most important thing for me to be working on at this moment?

important vs. urgent

One reason people who respect your time interrupt you is that they believe that the activity requiring your participation is urgent. And if the activity they are interrupting is actual programming, you probably view them as impeding your ability to accomplish something important.

One model for understanding the conflict is to judge activities on two orthogonal scales: importance, which measures long-term value and assumes that you can perform the task now or later, and urgency, which measures the degree to which the value of a task declines if you execute it later.

(Of course, both scales go into the negative as well as the positive. So the value of writing a rent cheque is that you avoid an incredibly negative outcome in the future).

If the quasi-economic explanation of the difference doesn’t strike a chord, try the exercise Steven Covey suggests in his book The 7 Habits of Highly Effective People: Look back on last year. The whole year. Now ask yourself: of all the things you wanted to accomplish, what would you like to have done if you had more time? Those things are the things that were important but not urgent.

Making time to do things that are important but not urgent is one of life’s greatest challenges. Do you really want to learn a new programming language? Network with more people? Read more books? Visit your mother more often? You need to make the time to make it happen. You need to find a way to take time away from urgent activities and give it to important activities.

A reasonable explanation for the conflict between the boss who wants status now and the programmer who wants to get into the flow and complete the work is that the programmer is concentrating on the important while the boss is concentrating on the urgent.

After all, if it wasn’t urgent, the boss would request status by email, or wait for the next daily meeting we have on that particular project. She’s no dummy, she wouldn’t be asking now if she didn’t need an answer now.

And if it wasn’t important, the programmer wouldn’t be so obsessed with trying to focus and do it right, trying to think all of the consequences and cases through so as to produce a really solid piece of code.

To summarize, one reason people who respect your time interrupt you is that they believe that the activity requiring your participation is urgent. And if the activity they are interrupting is actual programming, you probably view them as impeding your ability to accomplish something important.

optimization

There’s another important factor to consider. Let’s say that you and your boss synchronize on importance and urgency. Let’s say you see eye to eye on how to evaluate what you ought to be doing at any one moment in time. Can you now allow your boss to interrupt you at will and still maximize the value you provide to her?

This is a trick question. What does it mean “to evaluate what you ought to be doing at any one moment in time?” Does it mean that you can look at all the data in front of you, stuff it into some kind of choice function, and out pops the activity you ought to be doing?

The answer for my fellow programmers is, Yes, but the function is a closure.

In other words, local maxima are not global maxima. Or if you like compilers, peephole optimization is most pessimum.

Let’s take an example. What’s the best use of your time right now? Programming? Ok, why isn’t that the best use of your time 24/7/365? Forget sleep and social interaction and other non-work things if that seems complicated. Let’s just think about work. Why do anything else while you’re at work? The answer, of course, is that the optimal use of your time involves a balance between different ways of producing value.

Code is more important than documents. But code without any documents, ever, is less valuable than code with a certain amount of well-written documentation. And a lead programmer needs to write code. But they also need to coach their colleagues. So why don’t they just code? Or just coach?

It turns out that people who just coach, consultants… oh well, you can fill that one in. And more than a few electrons have zipped through the pipes about programmers who only produce code, but never interact with their colleagues. Most teams need leads who have a balance between producing code and raising the value of their colleagues.

Another classic example is a bug. Stuart reports a bug in Sally’s code. It doesn’t erase user data or install a root kit. Should Sally fix it? Stupid question. Once you leave the comfort of a weblog, you know that you cannot evaluate any but the most catastrophic show-stoppers individually. If you try to make these decisions one at a time, you invariably will work on the wrong things. You need to establish a rhythm of bug triage meetings, so that at any one time you are looking at enough bugs that you can choose those with the highest value and skip those that are not relatively important.

Balancing activities to produce the overall maximum value for your team (or yourself if you are a team of one) requires a broad view of your priorities and activities, just like triaging bugs requires a broad view of the outstanding issues with a release. You can’t make those decisions on a report-by-report basis, you need to optimize globally.

Which leads us back to interruptions. The primary issue with an interrupt-driven culture is not that people don’t respect each other’s time. It’s that making decisions on a moment-by-moment basis means you never have the perspective with respect to what’s important and to the overall balance of what you need to be doing to maximize the value you deliver to your team.

That’s why time management systems like Getting Things Done place such a premium on daily and weekly reviews: you can’t be effective if you are a slave to the to do list and never step back to optimize the value you create in your life.

Interruptions may maximize response to urgent issues. Interruptions may appear to be the best use of your time given the information the interrupter has at the time. But other people almost never have all the information you have to know what you need to be doing right now, so for this reason regular interruptions sacrifice your global maximum value for the appearance of local maximum.

And for that reason, it is easy for other people to have the utmost respect for the value of my time but still impeded me from providing the maximum value to our team if they chose to interrupt me rather than using asynchronous channels like email.

so it’s wrong to interrupt programmers?

In general, if what you want from programmers are working programs, don’t interrupt them. Maximize their programming productivity in every way you know how.

But don’t you think the managers running an “interrupt-driven” workplace know that? Of course they do. They know how to maximize the production of programs, starting with hiring great programmers and working from there. If they aren’t doing those kinds of things, it may be that they aren’t trying to maximize programming productivity.

There could be many reasons for this. Perhaps they run their business on a time and materials basis, so they are trying to maximize customer service while optimizing for the cost of labour. A programmer who wishes to be successful in a particular culture should be careful that programming is really their boss’ number one priority before trying to optimize their personal programming productivity.

The bottom line, again, is that their colleagues may respect their time to the utmost, but not believe that it is best spent with their head down programming.

In that case, the only problem I have with interruptions is the realization that what I think is important is out of sync with what the team thinks is important.  ¶ 5:21 PM