I thought I'd take a moment to share my email "system". This is the method I use to keep from becoming overwhelmed by the volumes of email I get, and also make sure that nothing important slips through the cracks and is missed.
I've cribbed heavily from David Allen's Getting Things Done in putting this together for myself - if you try this out and like what you see, consider it a teaser for the complete time management system David describes in his book.
On to my system...
I have six mail folders. The first two are Inbox and Sent. Most email software gives you those by default.
I have added four others: Actions, Reading, Waiting, and Saved.
So my complete email folder list is:
Inbox
Sent
Actions
Reading
Waiting
Saved
The key to this system, and to many other methods, is that the Inbox is always empty. Always. Whenever I check my email, the goal is to empty my Inbox.
How to empty the Inbox:
One by one, open each email.
Can I delete the email immediately? If yes, then I do so and move on.
Can I deal with the email in the next minute or so? If so, then I deal with it, and file the email in Saved.
Otherwise, I file the email in one of my folders.
Actions is for mail that I need to respond to, or requires some action on my part.
Waiting is for mail I need to somehow follow up on, or wait for a response.
Reading is for things I want to read, but require no follow-up from me, and are not especially time-sensitive. This is the only folder I use "rules" to automatically sort mail into.
Everything else gets filed in Saved. Yikes! How will I ever find it again??? More on this in a minute.
There's one more folder in my system: Sent.
I treat the Sent folder just like my Inbox. I keep it empty. Quite a lot of the time, I can just file the email in Saved. But if I've committed to further action, or delegated a task to someone else and want to maintain awareness and follow-up, I will file the email in Actions or Waiting.
Ok, what about this filing everything in Saved? How can I organize all my email by project, or recipient, or month sent, or priority, or whatever other method I want to use?
I used to spend time filing my email into different folders for different purposes, but I don't bother with that any longer since I started using a good search tool for my email. I've been using Copernic Desktop Search, and am very happy with it. I can always find anything I'm looking for much faster than the bad old way, and I never have to maintain my filing system, or decide where something goes.
If you like what you've seen so far, check out David Allen's Getting Things Done: The Art of Stress-Free Productivity.
Wednesday, March 30, 2005
Slacker Manager: Manager-chair philosopher
Brendon Connelly at Slacker Manager offers these thoughts about the importance of having a philosophy of leadership or management, and particularly about his own philosophy. The bottom line, he says, is this: "Model the behavior you're looking for and you'll start to see it".
I couldn't agree more, particularly when it comes to attitude. If you bring a negative attitude to your leadership style - if you focus on what not to do, or what is wrong with things, or why someone's idea can't work - that attitude will permeate the people around you. If instead, you "remove roadblocks", focus on what works - that will spread, too.
If you're stuck in a negative frame of mind, then take a minute to shift gears. Try saying to yourself (or to the person you're talking to): "Okay, those are some reasons this thing hasn't caught on yet. Let's think of some ways that we can make it work for us."
I couldn't agree more, particularly when it comes to attitude. If you bring a negative attitude to your leadership style - if you focus on what not to do, or what is wrong with things, or why someone's idea can't work - that attitude will permeate the people around you. If instead, you "remove roadblocks", focus on what works - that will spread, too.
If you're stuck in a negative frame of mind, then take a minute to shift gears. Try saying to yourself (or to the person you're talking to): "Okay, those are some reasons this thing hasn't caught on yet. Let's think of some ways that we can make it work for us."
Tuesday, March 22, 2005
Schedule Slippage and, um, Golf
Around the Boston area, golf is a seasonal activity (well, for most of us). With a couple days of good weather ushering in Spring's return, I've been itching to hit the links again.
I started playing a few years ago - and I'm not very good, but it's a fun game. Par is usually around 72 strokes for an 18 hole course. I consider myself extraordinarily fortunate to break 100 strokes. Well, ok, I did it once. Alone. In the rain.
So, a typical round of golf for me is to be about 2 strokes over for each hole. On a par 3 hole, I'll get a 5. On a par 4, I'll get a 6. I'm thrilled when I make par for a hole - and occasionally I do. And then occasionally, it'll take me more than 2 strokes over par to get the ball into the cup.
Still, ever the optimist, if after 3 holes, I'm 6 over par, I'll estimate my final score at 78, because I assume I'll make par on the remaining 15 holes.
Of course, I know that's not really what will happen. I'll probably get about a 106, because I'll probably be a similar amount over par on every single hole. And if by chance I make par (or even under par) on a hole or two, I'll probably make up for it by being even more over par on another hole.
Ok, I'll stop talking in code now. This is a real-world problem with the usual approach to updating software project plans to account for slippage. (We lost a day? Add a day to our rosy optimistic schedule.)
If after two months of a six month project, you're a month behind - I've got news for you. You're probably on a 12 month project, not a seven month project.
I started playing a few years ago - and I'm not very good, but it's a fun game. Par is usually around 72 strokes for an 18 hole course. I consider myself extraordinarily fortunate to break 100 strokes. Well, ok, I did it once. Alone. In the rain.
So, a typical round of golf for me is to be about 2 strokes over for each hole. On a par 3 hole, I'll get a 5. On a par 4, I'll get a 6. I'm thrilled when I make par for a hole - and occasionally I do. And then occasionally, it'll take me more than 2 strokes over par to get the ball into the cup.
Still, ever the optimist, if after 3 holes, I'm 6 over par, I'll estimate my final score at 78, because I assume I'll make par on the remaining 15 holes.
Of course, I know that's not really what will happen. I'll probably get about a 106, because I'll probably be a similar amount over par on every single hole. And if by chance I make par (or even under par) on a hole or two, I'll probably make up for it by being even more over par on another hole.
Ok, I'll stop talking in code now. This is a real-world problem with the usual approach to updating software project plans to account for slippage. (We lost a day? Add a day to our rosy optimistic schedule.)
If after two months of a six month project, you're a month behind - I've got news for you. You're probably on a 12 month project, not a seven month project.
Good, Fast or Cheap Part II: So what?
So, despite the fact that the old rubrick "Good, fast, or cheap: pick two," does nothing to help us improve our software devleopment efforts - why does it still resonate so much with us, as developers? I think it's a refuge where we express our frustration with schedule and budget pressure that seems unreasonable to us, given that we need to produce software that works.
Nonetheless the reality is that any software effort has to deliver within the constraints of time, budget and quality. What we should really be doing when we're faced with time and budget constraints that seem inadequate to the task, is to express that. If we are sincere, then the effort should be avoided to begin with - or negotiations need to be made which will produce a valued product within reasonable constraints.
Nonetheless the reality is that any software effort has to deliver within the constraints of time, budget and quality. What we should really be doing when we're faced with time and budget constraints that seem inadequate to the task, is to express that. If we are sincere, then the effort should be avoided to begin with - or negotiations need to be made which will produce a valued product within reasonable constraints.
Thursday, March 17, 2005
Communication skills for software developers
In my previous post, I suggested that just improving communication skills could have a powerful effect on your efficiency in developing software. What was I talking about?
Let's take meeting skills, for one. Software developers facilitate and participate in a lot of meetings. There are some skills you can bring to bear to make those meetings more effective.
1. Are you a good meeting scheduler?
Do you prepare an agenda in advance, and distribute it to the participants, so that they know how they will be spending their time?
Do you make it clear what results you want to achieve by the end of the meeting?
Do you give participants suffient time to prepare for a meeting before holding it? Or do you grab a few people (or a single person) in the hallway while it's on your mind and just get their gut reactions?
Do you make sure to invite everybody who has something valuable to contribute, or has a say in decision-making? Otherwise you may find yourself revisiting everything again later.
2. Are you a good meeting facilitator?
Do you follow the scheduled agenda?
Do you make sure everyone gets a chance to provide their input, and assure nobody dominates the meeting (especially yourself)?
Do you steer people back to the topic at hand when they get off track?
3. Are you a good meeting recorder?
Do you make sure to accurately capture important information and decisions? Do you confirm with the group that you've done so before moving on?
Do you write legibly on whiteboards and flipcharts? Do you use them at all?
Do you provide complete meeting notes to those who attended the meeting, and to other interested parties?
There are other, more specific skills and tools you might bring to a brainstorming session, or a requirements gathering session, or a decision-making session.
As you become better at conducting good meetings, you'll find that you spend less time on them, and the results are more valuable.
Interested in learning more about effective meetings? Try How to Make Meetings Work: The New Interaction Method.
Let's take meeting skills, for one. Software developers facilitate and participate in a lot of meetings. There are some skills you can bring to bear to make those meetings more effective.
1. Are you a good meeting scheduler?
Do you prepare an agenda in advance, and distribute it to the participants, so that they know how they will be spending their time?
Do you make it clear what results you want to achieve by the end of the meeting?
Do you give participants suffient time to prepare for a meeting before holding it? Or do you grab a few people (or a single person) in the hallway while it's on your mind and just get their gut reactions?
Do you make sure to invite everybody who has something valuable to contribute, or has a say in decision-making? Otherwise you may find yourself revisiting everything again later.
2. Are you a good meeting facilitator?
Do you follow the scheduled agenda?
Do you make sure everyone gets a chance to provide their input, and assure nobody dominates the meeting (especially yourself)?
Do you steer people back to the topic at hand when they get off track?
3. Are you a good meeting recorder?
Do you make sure to accurately capture important information and decisions? Do you confirm with the group that you've done so before moving on?
Do you write legibly on whiteboards and flipcharts? Do you use them at all?
Do you provide complete meeting notes to those who attended the meeting, and to other interested parties?
There are other, more specific skills and tools you might bring to a brainstorming session, or a requirements gathering session, or a decision-making session.
As you become better at conducting good meetings, you'll find that you spend less time on them, and the results are more valuable.
Interested in learning more about effective meetings? Try How to Make Meetings Work: The New Interaction Method.
Tuesday, March 15, 2005
Good, Fast or Cheap: BS Alert
You'll hear a lot of developers talk about the old saw: "You can have software good, fast, or cheap: pick two". Now, given an unchangeable set of people, processes, and technology, that might hold true. However, the reality is, you can have things better, faster, and cheaper, simply by improving the efficiency of your approach. That usually boils down to just improving the way you conduct the activities of software project management, and the specific activities that contribute to creating the software. Even just improving communication skills can have a dramatic effect on software project efficiency.
The other issue with this good/fast/cheap BS is that it implies once you've picked the two you care about, you can stop worrying about how to achieve the other one, and that is simply not true. You can't ignore quality, time, or expense - these are all constant considerations.
Similarly, it suggests that by throwing money, or time, or bugs(!) at a system, you can get the other two factors to go up, and again that is absolutely not true.
So the response this always gets from me is: That's an interesting observation... so what?
There are always real-world business constraints on time, quality, and expense. The real blood and guts of the matter is this: What is your capability to produce a given project within those constraints? The only way to improve your capability is to improve your efficiency.
A side effect when you improve your efficiency is that you improve on all three indices - better quality, shorter turnaround, and lower costs.
The other issue with this good/fast/cheap BS is that it implies once you've picked the two you care about, you can stop worrying about how to achieve the other one, and that is simply not true. You can't ignore quality, time, or expense - these are all constant considerations.
Similarly, it suggests that by throwing money, or time, or bugs(!) at a system, you can get the other two factors to go up, and again that is absolutely not true.
So the response this always gets from me is: That's an interesting observation... so what?
There are always real-world business constraints on time, quality, and expense. The real blood and guts of the matter is this: What is your capability to produce a given project within those constraints? The only way to improve your capability is to improve your efficiency.
A side effect when you improve your efficiency is that you improve on all three indices - better quality, shorter turnaround, and lower costs.
Subscribe to:
Posts (Atom)