Here are some tips for those of us makers that are forced to be on a manager's schedule from time to time:
Meeting avoidance techniques
-Pickup the phone if an email thread gets longer than 3 emails. Long email threads are the carrots that dangle in front of a potential meeting coordinator. A phone call, while disruptive, can often clarify things better than any email could, and since you're checking email at the time you make the call, you probably weren't hacking (or at least in the zone) anyway.
-Status meetings are the professional equivalent of asking "are we there yet?" for the 50th time in sweltering heat. If you get called into a status meeting more than once a week, it is time to address it as a problem. Most managers you are dealing with are only concerned about two things: what you're doing and when you expect it to be done. Get good at demonstrating what you have done. Perhaps adopt a build schedule with each build having demonstrable qualities to it rather than things a manager cannot see/measure. Having a build and demonstrating it with a statement like "I refactored all my code so it's much easier to maintain" is wonderful, except to a manager who might second-guess that you did any work at all since nothing appears to have changed for you. Similarly, get good at tracking your time. You can only do this by actually tracking how much time you spend on things. There are good tools available to accomplish this, so do it. When you go to make future estimates, they may not be precise but at least they'll be a lot more accurate than simply guessing.
-Ever had two half-hour meetings scheduled over the course of a few days? Look at opportunities to defragment your schedule. If you have two meetings with the same person, see if you can combine them into one mega-meeting. If you have a meeting one afternoon with manager A, and a meeting the next morning with manager B, call them up and see if you can re-schedule the meeting. You have the same capacity file systems (schedules), but your block size is bigger than theirs and so you have fewer of them. A measly half hour meeting will take up one gigantic block of your schedule while it will only take up a small block in theirs. Thus, from a purely statistical point of view, the chances of having them say yes to a reschedule are quite high.
-If you are on a development team, create a designated hitter of meeting attendees. Take turns being the DH. Personally, I prefer to have one week where I'm stuck in manager mode rather than having to go into manager mode once a week. You'd be surprised how often the specific programmer responsible for a piece of code is actually needed at a meeting. Often they just need a technical person's opinion, and chances are that you can assert your team members' opinions for them. When it comes to schedule estimates, you probably have a rough idea of how quickly your teammates work and when pushed for an estimate, so as not to pressure them, you will probably sandbag your estimate more than if they were to ask the same of you. So it works out better anyway because you're building contingencies into your time estimates.
If you have to schedule meetings:
-Add a custom field to each business contact with their meeting time preference: "Morning", "Early Afternoon", "Late Afternoon", "Evening", etc.
-When you go to book meetings, try to book them all on one day, a task that will be made easier because you can preemptively suggest their preferred time.
If you run a meeting, do it well:
-Run your meeting like the Japanese railway system. Each invite should include the length of the meeting, an agenda, and what you will accomplish by meeting.
-The day before the meeting if it is in the morning (or several hours before hand if in the afternoon), send out a revised agenda and confirmation. Who knows, you may not have to attend the meeting, but at least you'll have a nice 3 hour window ahead of you before finding out. This means the day ahead is free!
-While at the meeting, keep track of the time and keep people focussed. You don't have to be a jerk, but gently guide people back on topic when they start talking about the weather.
-After the meeting, volunteer to send out the meeting minutes. This will ensure that all next-actions/deliverables are recorded and will minimize future interruptions by email/phone/further meetings.
-Chances are that your meetings are not run like the ones above if you're simply an attendee. If you are an employee, see if you can get your boss to sit in on meetings and be your delegate. If you are in an environment that will allow you to, introduce this kind of behaviour. Too many professionals simply aren't aware of how meetings should be run, so they do things in a sloppy manner.
Meeting avoidance techniques
-Pickup the phone if an email thread gets longer than 3 emails. Long email threads are the carrots that dangle in front of a potential meeting coordinator. A phone call, while disruptive, can often clarify things better than any email could, and since you're checking email at the time you make the call, you probably weren't hacking (or at least in the zone) anyway.
-Status meetings are the professional equivalent of asking "are we there yet?" for the 50th time in sweltering heat. If you get called into a status meeting more than once a week, it is time to address it as a problem. Most managers you are dealing with are only concerned about two things: what you're doing and when you expect it to be done. Get good at demonstrating what you have done. Perhaps adopt a build schedule with each build having demonstrable qualities to it rather than things a manager cannot see/measure. Having a build and demonstrating it with a statement like "I refactored all my code so it's much easier to maintain" is wonderful, except to a manager who might second-guess that you did any work at all since nothing appears to have changed for you. Similarly, get good at tracking your time. You can only do this by actually tracking how much time you spend on things. There are good tools available to accomplish this, so do it. When you go to make future estimates, they may not be precise but at least they'll be a lot more accurate than simply guessing.
-Ever had two half-hour meetings scheduled over the course of a few days? Look at opportunities to defragment your schedule. If you have two meetings with the same person, see if you can combine them into one mega-meeting. If you have a meeting one afternoon with manager A, and a meeting the next morning with manager B, call them up and see if you can re-schedule the meeting. You have the same capacity file systems (schedules), but your block size is bigger than theirs and so you have fewer of them. A measly half hour meeting will take up one gigantic block of your schedule while it will only take up a small block in theirs. Thus, from a purely statistical point of view, the chances of having them say yes to a reschedule are quite high.
-If you are on a development team, create a designated hitter of meeting attendees. Take turns being the DH. Personally, I prefer to have one week where I'm stuck in manager mode rather than having to go into manager mode once a week. You'd be surprised how often the specific programmer responsible for a piece of code is actually needed at a meeting. Often they just need a technical person's opinion, and chances are that you can assert your team members' opinions for them. When it comes to schedule estimates, you probably have a rough idea of how quickly your teammates work and when pushed for an estimate, so as not to pressure them, you will probably sandbag your estimate more than if they were to ask the same of you. So it works out better anyway because you're building contingencies into your time estimates.
If you have to schedule meetings:
-Add a custom field to each business contact with their meeting time preference: "Morning", "Early Afternoon", "Late Afternoon", "Evening", etc.
-When you go to book meetings, try to book them all on one day, a task that will be made easier because you can preemptively suggest their preferred time.
If you run a meeting, do it well:
-Run your meeting like the Japanese railway system. Each invite should include the length of the meeting, an agenda, and what you will accomplish by meeting.
-The day before the meeting if it is in the morning (or several hours before hand if in the afternoon), send out a revised agenda and confirmation. Who knows, you may not have to attend the meeting, but at least you'll have a nice 3 hour window ahead of you before finding out. This means the day ahead is free!
-While at the meeting, keep track of the time and keep people focussed. You don't have to be a jerk, but gently guide people back on topic when they start talking about the weather.
-After the meeting, volunteer to send out the meeting minutes. This will ensure that all next-actions/deliverables are recorded and will minimize future interruptions by email/phone/further meetings.
-Chances are that your meetings are not run like the ones above if you're simply an attendee. If you are an employee, see if you can get your boss to sit in on meetings and be your delegate. If you are in an environment that will allow you to, introduce this kind of behaviour. Too many professionals simply aren't aware of how meetings should be run, so they do things in a sloppy manner.