Scheduling Under Pressure – Best Tactics

14:50 Delegate

“If it isn’t your problem it isn’t a problem.”

If you can’t do the work, someone else probably can. Even if you aren’t in management, you can often convince management to assign some tasks to other people, especially if you can make a good case for doing so. If you are on a team with multiple people, make sure that you and the other people on the team are working on the tasks at which you have the most skill. This is no time for cross-training.

This is defensible simply because you can only do so much. You do need to be prepared to show that you can’t do any more in a standard workday. Another good way to make a case for this is to delegate lower value or less critical tasks.

18:10 Prioritize the work you do based on project critical path

A task is on the critical path of a project if it is part of the tasks required to complete the project in the minimum amount of time. A way to think about this is that if a task on the critical path is delayed, the project completion is delayed. Handling things on the critical path means that other people aren’t waiting on you, which keeps management off your back.

Handling the critical path tasks first is defensible for a number of reasons. It keeps you from looking slow, because people aren’t always complaining about waiting on you. It helps avoid crisis situations where delivery dates aren’t met. If your manager tells you to do something else, be sure to get written documentation.

22:45 Set aside blocks of time for focused work

One reason developers are commonly overloaded is that they aren’t able to concentrate on their work long enough to get it done due to company mandated context switching. Many managers, especially people with no development experience, react to impending missed deadlines by panicking and scheduling more meetings. You will have to fight for blocks of time to get stuff done.

This is a hard practice to defend, but you must if you want to succeed. Try to convince management to restrict meetings and other interruptions to predictable times. If they won’t, then your project will fail. Some developers will work after hours to get this time. It’s not recommended, but you can get away with it for short bursts. It’s almost always a terrible idea.

31:25 Shut out distractions

Similar to the interruptions posed by meetings, other distractions from inconsiderate (or clueless) people can be very damaging to your ability to focus. This can be anything from loud talking, to random announcements coming over the loudspeaker. This can include visual distractions as well. It basically works for anything environmental that impedes your progress and breaks your focus on a frequent, unscheduled basis. You will need to get away from the distractions. This may mean using a different office, or even working from home. Noise-cancelling headphones are usually not enough for this.

This one is also a hard sell to management. After all, if they thought this was damaging productivity, they would have fixed it already. It’s also very easy to sound whiney when suggesting environmental changes.

36:40 Force breaks

This one is counter-intuitive, but critical. A naive understanding of software development tends to make people think that working more will produce more, but that often isn’t the case, for a variety of reasons. First of all, having less time to accomplish a given (small) task will often make you more selective about how to implement it. Second, all developers can struggle with a bug for hours, and fix it in a few minutes the next day. Your brain will often present you with a solution when you aren’t focused on it. This phenomenon is why many people come up with impressive insights while on walks, in the shower, or in the dead of night.

This one is also hard to defend. Especially if your managers don’t have software development experience. It gets even more tricky to defend if other, previous developers took an excessive number of breaks and didn’t produce results. You may not be able to get a “real” break if your management is particularly bad on this. However, you may be able to get away with a quick run down the hall to get coffee. If nothing else, make sure that you take lunch breaks away from your desk.

40:55 Insist on clear specifications

Another issue that destroys developer productivity and makes deadlines harder occurs when specifications are ambiguous (or non-existent). Unless it is specifically part of your job to do technical specifications, you shouldn’t be spending time trying to figure out what they mean under deadline pressure. Bad specifications can cause you to waste time producing features that aren’t needed, or incorrectly implementing features that are needed. Many developers also get extremely stressed when attempting to figure out unclear documentation, to the point that the number of mistakes they make increases. This may be you or it may be other people on the team.

This one is liable to tangle you up in office politics. It’s easy for this to be interpreted as trying to shift the blame to someone else. If management is in charge of specifications, this will end badly. You are probably better off asking lots of questions for clarification, as doing so also helps improve the quality of the specifications over time.

42:45 Insist on asynchronous communication methods and only check them at specific times.

This typically means turning off slack, email, text notifications, and your desk phone. Obviously, these things are distractions, especially if you check them frequently. However, even if they aren’t actively distracting, the possibility of a distraction is often enough to slow you down. Think about how you code when you know that no one is going to bother you, versus how you code when someone might interrupt you at any moment. You should probably also turn off notifications on your phone, except for a few people who might contact you in an emergency.

This one is pretty easy to justify to management. Most software development managers know how bad interruptions are for productivity. They are also usually aware of how many notifications the average developer gets and how few of them are valuable. You may have some difficulty completely ignoring email, slack, and your desk phone, especially if management is relying on a prompt answer from you. If this is the case, one good strategy that will work is to ask which thing has priority, your actual task, or the random interruptions.

47:15 Ask for stuff before you need it

Another thing that makes scheduling difficult is waiting on other people. The task you’ve given them might not take much time, but if they are similarly overloaded (or worse, they are the slowpoke who is making everyone else overloaded). In addition, the stuff you are asking for might not be their top priority, for a variety of reasons. This can occur even if your project is top priority. The sort of environments that regularly have crunch time almost always have issues with either being understaffed, or with inconsistent project prioritization (usually both). Asking for things ahead of needing them will help avoid those problems becoming your problem.

You probably won’t have to justify this to management unless you are being micromanaged. It’s expected that people ask for things they need while working. If you do it ahead of time, it just means you’re an adult. Honestly, nobody really notices this kind of thing unless the environment is so bad that you can’t fix it anyway.

49:45 Spend appropriate/more time on project dependency planning

Your projects will take longer if you do things in the wrong order. Not only does doing stuff in the wrong order often mean that you stop in the middle of the work to work on prerequisites, but doing so can often mean reworking code that is already written. You’ll also generally find that you have more errors in code if you are interrupted for an extended period while writing it. Coding errors will come back and cause you problems later when it is tested.

This can be tricky to sell to management, especially if they made the project plan. However, if you have any control over which tasks you take on first, you can pick the ones that you believe are most critical to getting things done. Be sure and be able to defend your decision however. It won’t go well if you are wrong, but if you are right, your initiative may be appreciated.