Category Archives: Management

Your Annual Plan Is Already Wrong

Management, Process

Your year-at-a-time plans and goals are already wrong, but if you know this about them, they are still worth making, provided you don’t take them too seriously.

Another January is upon us, bringing us into the season of annual planning exercises. Annual plans are the organizational equivalent of New Year’s resolutions – we feel obligated to make them, even though we are unlikely to keep them.

In most organizations, there is little practical difference between the end of December and the beginning of January, and so there are few objective grounds for over-weighting this part of the year as a time for course corrections and new ventures. Yet, the unblemished calendar invites us, like fresh snow, to create something remarkable upon its canvas. We aspire to high art, and this seemingly demands a plan that will keep us from wandering around in circles, doubling back over our tracks, and generally making a mess of the yard.

My friends, the mess is unavoidable. Success is rarely achieved in a straight line.

We should no longer be surprised by the annual objectives which seemed so central in January and were scarcely relevant by June. We can hardly doubt that our signature accomplishments in a given year were often unimagined at the start of that year. If we are attentive and realistic, we recognize that these discrepancies between planned and actual are as much the norm as the exception.

Humans are poor planners and feeble fortune tellers, and pretending otherwise amounts to damaging obstinacy. Let us instead embrace our obvious limitations and our well-documented fallibility, so that we can prepare and act accordingly. We are equipped with lanterns, not flashlights. We can see what is close at hand, but most of the path before us will remain dark until we are right on top of it.

The rise of agile software development methods is an outgrowth of this recognition. Agilists accept that they cannot see the future very well. They don’t try to look very far ahead because people simply aren’t very good at doing so and because changing circumstances often invalidate plans made on large time scales. Instead, agilists work in small iterations, experimenting and successively refining until they have made their way to their goal. With each iteration of their output, they evaluate what they have done so far and what the next best thing to do would be. They keep long range goals in mind as a guiding star, but they navigate in the moment by more immediate and accessible beacons. If they make a mistake, they won’t go very far before giving themselves a chance to correct it and get back on course.

The corollary lessons for annual planning exercises, including personal goals, are clear. If your planning cycle is annual, then your plan is already wrong, not because of its established content but because it doesn’t contain realistic mechanisms for error correction and adjusting to change. The winds of the world are abrupt and fickle, and we can’t keep sailing in the right direction by changing our tack on a merely annual basis.

Instead of planning annually, organizations should:

  • plan for multiple time horizons, such as “within three months,” “within six months,” “within a year,” and so on
  • make near-term plans the most detailed (because these cover the ground we can actually see well)
  • make long-term plans more directional and less defined
  • revisit plans regularly, multiple times within a year, for review and adjustment
  • accept that plans sometimes turn out to be wrong, and that there is no shame in adjusting to new information or realizations

The annual plan is a fossil, left over from the days in which things moved slower and we knew less about ourselves. It’s time for us to evolve into planning cycles that are more natural, realistic, and credible.

Defining a Strategy: A Useful Test

Management, Strategy

You don’t have a strategy until somebody thinks it isn’t a good idea.

Here’s a simple test for any strategy you’ve defined – can you think of an organization that wouldn’t be following the same strategy? If not, then you’ve only defined a goal, not a strategy.

“Cutting costs” is not a strategy. Everybody wants to do that. If you say something about how you will do that (what you will consciously sacrifice in order to cut costs), and not every organization would have the same answer (hint: “eliminate waste” and “streamline operations” are too generic / formulaic to count), then you are on your way to a strategy.

A strategy must give some indication of how you will be different from your competitors. You don’t have a strategy until somebody thinks it isn’t a good idea. Having the right strategy is a much more complicated matter, but the test above (i.e., would anybody do otherwise?) will keep you from settling on generic pablum that lends only the illusion of strategic thinking.

Rules for Meeting on the Maker’s Schedule

Improving, Management, Tips,

Schedule your meetings in a way that is cognizant of the significant difference between the maker’s schedule and the manager’s schedule.

If you manage people who are building software or otherwise doing something that requires sustained, intensive concentration, then this is something you need to read:

http://www.paulgraham.com/makersschedule.html

The basic gist of the essay is that the “tax” of holding a meeting is many times worse for a maker (people who build things, and require sustained concentration to do so) than for a manager. The manager tends to view the day as a series of hour-long slots into which obligations, especially meetings, must be fit. The maker, however, tries to get large blocks of uninterrupted time, because of the effort required to get back into the creative “zone” after an interruption. For a maker, three contiguous hours are much more valuable than three isolated hours. A typical software developer will get twice as much coding done from 1:00 to 4:00 as she would from 9:00 to 10:00, 11:00 to 12:00, and 2:00 to 3:00, even though the total time spent seems to be the same in both scenarios.

After reading this article, I now try to schedule meetings using the following rules, which assume that I can see the daily calendars of the makers with whom I’d like to meet:

1) If a maker already has an uninterrupted morning or afternoon, don’t touch it. That’s golden time, and biting into it is like cutting open the golden goose. Find another time. (This rule decreases greatly in importance if the maker appears to have lots of unscheduled time, but most engineers / developers have a decent number of meetings that they need to attend.)

2) Try to schedule the meeting adjacent to existing meetings, preferably on the side that allows the block of time on the opposite side to be as large as possible.

3) If the above don’t work out, schedule the meeting immediately before or after lunch.

4) As a corollary consideration, schedule your meetings with other managers at times like 10:00 AM and 2:00 PM, so that you will be free to meet with makers (as needed) on a schedule that is more congenial to their interests.

I’ve been trying to follow these rules for a month or so, and my folks think they make a difference. They report a little more time to tackle hard problems, and they appreciate the fact that I am cognizant of their scheduling needs . Of course, there are times when I have to violate the rules, particularly when the meeting is large (making it much harder to find common free time) or when it involves somebody who is chronically over-scheduled. For example, my boss has an amazingly small amount of uncalendared time in any given week, and so if I need to get him in a meeting with my folks, I’m pretty much bound to pick whatever free time he might have.

My scheduling concerns are relatively complicated because I have a geographically distributed team, part of which is on eastern time (Philadelphia) and part of which is on mountain time (Denver). So, for team meetings, it’s harder to get a time that works for everybody. 11:00 AM eastern works pretty well because the Philly folks will go to lunch right after and the Denver folks (2 hours behind) are just starting their day. 1:00 PM eastern is also good for similar reasons (Philly folks have lunch before, and Denver folks go to lunch after).

The difference between maker’s time and manager’s time is pretty obvious in retrospect, but most managers are surprisingly oblivious to it until it is pointed out to them. (I was.) Accounting for the difference is relatively simple, and likely to pay big dividends. So, I’d recommend coming up with your own set of rules for meeting on the maker’s schedule, and sharing them with the other managers in your organization. You’ll make your makers happy if you do.