What's Best Next

You are here: Home / Blog

Death by Meeting?

by

Seth Godin posted last week on Getting Serious About Your Meeting Problem. It was a good post, and brings up some things I’d like to develop further off and on.

For a longer treatment of the subject — and from a somewhat unexpected angle — I’d also recommend Patrick Lencioni’s Death by Meeting.

Lencioni’s premise in Death by Meeting is not what you might expect. He doesn’t jump on the usual bandwagon of trashing on meetings. In fact, he believes that the mindset of “if I didn’t have to go to meetings, I’d like my job more” is not a good one. It would be like a surgeon saying, “If I didn’t have to operate on people, I’d like my job more.”

So instead, Lencioni’s point is that we need to make meetings better. In fact, he argues that meetings should be more interesting than movies.

The reason most meetings are bad is that they lack two things: (1) context and (2) drama. The way to make meetings better, then, is to provide context and drama.

To provide context, he lays out the different kinds of meetings that should exist, and argues that harm is done when we combine incompatible things into the same meeting. For example, tactical and strategic meetings should be kept distinct. You shouldn’t bog down a strategic meeting with tactical issues.

Beyond this, meetings ought to be more interesting than movies because they actually affect reality. They key to making them so is drama. Not artifical drama, for sure. But by being willing to engage in constructive ideological conflict and mine for differences, meetings become naturally engaging, compelling, and energizing.

The Art of the Self-Imposed Deadline

by

Steven DeMaio has a helpful article on The Art of the Self-Imposed Deadline.

Before you check that out, it’s worth asking how self-imposed deadlines relate to GTD. For, on the face of it, self-imposed deadlines actually seem contrary to the “getting things done” approach. Here’s a quick word on that.

One of the principles of GTD is that you should only put deadlines on stuff that really has a deadline. This preserves your “hard landscape” so that you can make effective decisions, knowing what really is on a timeline and what isn’t.

It would be easy to take that counsel and then conclude that, therefore, we should never have self-imposed deadlines — that somehow self-imposed deadlines “don’t count” or “aren’t real,” but deadlines imposed by others somehow are.

But this would be a mistake. It would be a mistake to think that self-imposed deadlines aren’t valid, but deadlines imposed by others are.

The reason it is so easy to fall think that self-imposed deadlines aren’t real is that we tend to think that a self-imposed deadline is arbitrary. After all, we’re the one setting it. So why does it have to be Friday rather than next Wednesday?

But if you think about it, the same charge of arbitrariness could be made for deadlines that are assigned to us as well. After all, some person decided on that deadline as well. Why does that make it any less arbitrary than when we set the deadline ourselves?

The fact is that deadlines are a convention for keeping your work going along at the right clip. It is true that sometimes a deadline is an indication that things will completely fall apart if it is not made (for ex: I have to be at the airport in 1 hour, and here I am typing this blog post — better get this wrapped up!).

But the main value of deadlines is that they are a way to keep all your work from hitting at once, and to coordinate your work with the expectations of others so that they can fit your deliverables into their own consequent work in an orderly way. When this framework is behind your deadlines, they are not “arbitrary” but are in fact quite useful — and necessary.

In fact, without some manner of self-imposed deadlines on your work, you’ll either never get anything done, or you will never get any rest (because when nothing has a due date, your mind tends to feel like everything is always due right away — so you’ll feel like you should always be working).

The trick is, just don’t set too many deadlines. Use this tool, but use it wisely.

Well, with this said, go take a look at Steven DeMaio’s four tips for learning The Art of the Self-Imposed Deadline.

Key Notes from the Art of Project Management

by

Scott Berkun’s book The Art of Project Management (now issued in a new edition and renamed Making Things Happen: Mastering Project Management (Theory in Practice)) is the best book I’ve read on project management. It is fantastically helpful.

The other day I came across these brief notes I had jotted down a while ago from the book. They are very incomplete, hitting on just a few of the key things that stood out to me.

But sometimes, that’s what can be most helpful. So here they are, in case they might be timely for you as well:

  • Requirements vs. specifications. Requirements are the what, and specifications the how.
  • The three perspectives: Business (including marketing), technology, and user. User is most important but also most often neglected.
  • The importance of planning: “Plans provide an opportunity to review decisions, expose assumptions, and clarify agreements between people and organizations. Plans act as a forcing function against all kinds of stupidity because they demand the important issues be resolved while there is time to consider other options. As Abraham Lincoln said, ‘If I had six hours to cut down a tree, I’d spend four hours sharpening the axe,’ which I take to mean that smart preparation minimizes work.” (p. 41)
  • On thinking outside the box. It’s not always best to say “think outside the box.” Eliminating boxes is not necessarily the hard part—it’s knowing which boxes to use and when to use them. Constraints are ever present. Art of Project Management, 93. “Do whatever you want with the box. Think in the box, out of the box, on the box, under the box, tear apart and make a fire out of the box, whatever, as long as you manage to solve the problems identified as the goals for the project” (p. 94).
  • Where good ideas come from. To generate good ideas, ask good questions.
  • Open issues list: “An open issue is anything that needs to be decided or figured out but hasn’t happened yet. It’s essentially a list of questions, and it should encompass anything that needs to be done, prioritized by its potential impact on engineering” (123).
  • Different types of requirements and specs: Requirements, feature spec, technical specs, work-item list (the description of each programming assignment needed to fulfill the feature spec), and test criteria and milestone exit criteria (prioritized cases for the new functionality, along with goals for how well the code needs to perform on those cases to meet the quality goals for the milestone).

Facebook Connect

by

For those of you who haven’t yet informed yourself on what Facebook Connect is, here is a helpful summary.

Here’s the brief summary:

Facebook Connect is the next evolution of Facebook Platform, enabling you to integrate the power of Facebook Platform into your own site. Enable your users to:

  • Seamlessly “connect” their Facebook account and information with your site
  • Connect and find their friends who also use your site
  • Share information and actions on your site with their friends on Facebook

I think there are some very exciting things that will be happening because of this!

Estimate the Time on Your Projects

by

It can be useful to do a quick estimate of the time it will take to accomplish each of the projects on your project list.

I’ve never really done that before. I used to think that doing so would be an unnecessary exercise that would only serves to take time away from actually getting my projects done. And, beyond that, something that would evoke stares of disbelief from any who heard about it (“you actually do that?? what a waste of time! I just get everything done without any effort, and certainly without wasting in time in trivia like that!).

But I just did it (took less than 2 minutes) and discovered that I have about 63 hours of work staring at me simply from my list of current projects.

That’s very useful to know!

Assuming that I could devote 6 hours a day simply to project work (no email, no new tasks that come up, no meetings), it would take me just over two work weeks to finish that (assuming working only 40 hour weeks). And then, after that, there are a bunch of upcoming projects waiting in the wings.

When I factor in the doing of operational and routine things, that’s probably about a month’s worth of work.

It might be easy to conclude, then, that I have too much work on my current list.

But that’s not necessary too much — it just says that I am looking out about a month at a time on my projects list (not in due dates — many of the due dates are farther out — but in terms of work length). Having about a month active at a time is probably not necessarily a bad thing.

Now, I do try to keep my projects list as short as possible, and so maybe a month’s worth is to much to have on there. I do have more projects than normal active right now.

But the main issue is: Without having done this estimate, I wouldn’t know what quantity of work my projects list really represents.

But now that I know that, I can ask the next question: Is this what I really want to get done over the next month? If I did no other projects over the next month, would I be happy with the result? If not, what should I take off the list, and what should go on in its place?

The payoff in those questions is very high. But if I had not estimated the length of my current projects, my default would have been simply to try to cram new stuff in when it came up — without really knowing the trade-off in time delays it would cause.

Now, I can be more informed about those decisions and make sure I really am getting the right things done over the next month.