By Jarie Bolander,
Author of Frustration Free Technical Management
Building innovative products is an endurance event. Sprinters need not apply. Innovation takes time but cannot take so much time as to miss market windows. You need to pace yourself and your team. This is the only way to ensure consistent, quality results. The common trap of “we can just work 80 hour weeks” and get it all done on time just does not work. Make no mistake. You will work hard on your startup but you will burn the team out if you constantly have insane deadlines.

Urgency Yes, Panic No

Pace is important because it sets the cadence of the group. A sense of urgency should always be in the air but never a sense of panic. Panic is what slowly drives your people away and burns teams out. There will always be moments of panic. That is natural and unavoidable. The problem is when everyday is filled will panic. Not every problem is an emergency and not everything is a number one priority.

Too Much Of A Good Thing

Training for and running a marathon is a great lesson in pace. When I did my first marathon, I trained like mad for it. In fact, I overtrained (yes, you can over train). My incorrect assumption was that the more I trained, the better I would get. To a point, that works but when you over train, you don’t give your body enough time to fully absorb the training. You actually end up performing worst since your overtraining has taken too great a toll on your body. That is exactly what happened to me. I ran too much, too close to the race and ending up walking the last thirteen miles. I finished but I was so exhausted that I could barely stand up. This is the same thing that can happen to a development team. Too much hard work can prevent them from seeing critical issues. When it really counts, towards the end of the project, all the team wants to do is finish. This shifts the focus on getting it done instead of getting it right.

Set A Brisk Pace

You should be aggressive in your scheduling but realistic in your demands. Most technical people like a sense of urgency because it means that what they are doing is important. What they hate is a management team that puts their feet to the fire every waking moment. Teams need down time. They need to take a break every once and a while to refresh themselves and their skills. They also need time away from work so they don’t burn out. When deadlines are unrealistic and people get pushed to the breaking point, they tend to work hard but not smart. You can sense this by the mounting task list even though the number of hours worked has gone up. This is the first stage of team burn out. Once burn out sets in, it takes a long time to recover. Couple this with the pressure to meet deadlines and you will start to see your team unravel. Some will shut down while others will leave. When the pace is brisk but not insane, your team will sense the urgency but will also know that what is expected of them is reasonable. When the team feels that schedules are aggressive but reasonable, they will strive to meet them. They will go the extra mile to ensure the job gets done.

Agreement Does Not Mean Commitment

A place I used to work at would demand aggressive schedules even if they were unreasonable. The theory went that whatever schedule an engineer would come up with would be too conservative. This led management to push the staff aggressively since management figured whatever schedule was finally agreed upon would slip anyway. Most projects would go through this schedule dance until the project manager was so exhausted, he would agree. Once set in stone, the team would work like mad to get it done, knowing full well that the chances were slim to none that they would meet schedule. When the inevitable slip happened, management would go ballistic and demanded a detailed analysis as to why things went wrong. This made the team dread reporting a schedule slip to the point where no one would be proactive in solving problems – they would just wait until the last minute. This unrealistic, aggressive pace had the opposite effect – almost every project ended up being late not only to the aggressive schedule but to the originally proposed schedule.

Practical Pacing Techniques

Getting the pace right will lead to more productivity and happier team members. Get it wrong and you will constantly be behind and miserable. In order to achieve the optimum pace, consider the following techniques:

  1. Keep Features, Schedule and Budget In Mind: All projects conserve features, schedules and budgets. This means by constraining any two, the other will make up the slack. So, keep that in mind when projects start to slip or you want to add new features.
  2. Major/Minor Releases: The rhythm of the Major/Minor release gives teams a natural and consistent downtime. It also allows for features to be temporality delayed for the next release.
  3. Incremental Milestones: Tracking your incremental progress towards major milestones will pace your team to perform consistently instead of leaving all the work for the end. Make the incremental milestones meaningful and measurable.
  4. Quarterly Goals: Doing a quarterly goal plan is another great way to set the pace because if your team knows what they need to accomplish, they can work towards those goals on their own. It also shows that you value planning and firm requirements.
  5. Goal/Schedule By In: Critical to achieving your objectives is to define reasonable and rational goals and schedules. The best way to do that is to have your team set their own goals and schedules. As long as your team knows the constraints, they will strive to meet reasonable, even crazy, objectives.
  6. Don’t Change Requirements: The biggest time sync is the rework that happens when requirements constantly change. This wastes time and contributes to the frantic end game pace that burns teams out. So, avoid changing your requirements unless your team buys in.

In the end, you know your team and what motivates them to perform. By applying pacing techniques, you can make them more productive and happy while still meeting your critical deadlines.

Strive For Balance

There will be a constant battle between management reality (I want it done faster) and team reality (we are working as hard as we can). Translating between the two can drain even the most senior manager. The best tactic is to communicate the motivations for why deadlines are set. Remember that the natural pace of the team will always dictate when things get done, no matter how well you schedule, how smart they work or how much management wants it done faster. Balancing all of these factors will ensure that you take the time to not miss anything but hurry up so what you are creating is still relevant.
Author Bio
Jarie Bolander is an engineer by training and an entrepreneur by nature. He is presently VP of R&D at Tagent, a company working on breakthrough technology that will help reduce medical errors. Jarie also blogs about innovation, management and entrepreneurship at The Daily MBA and has recently published his first book, Frustration Free Technical Management. You can also follow him on Twitter @thedailymba


  1. I’ve found #6 in Practical Pacing Techniques to be very critical — changing requirements can kill a dev team. This can be a hard sell to management.
    My strategy has been that once a plan has buy in from everyone and is sent to the deve team, to go ahead and open up the first “change ticket” to collect all of the requirement changes that come in. The dev team should know about this “change ticket” but realize that it isn’t an approved plan and continue with the original requirements.
    It’s helpful because you are still capturing the changes, the developer’s know about the changes (and can take them into account in the current design if that makes sense), but the developers don’t feel knocked around on a sea of never ending changes.

  2. Pingback: MicroISV Digest – 01/13/2010

  3. Thanks for the excellent comments. I agree that changing requirements should be the number one thing to not do. Many a project has cratered because of the “sea of never ending changes.” It also messes with the groups pace and grove.

Reply To Mark L. Smith Cancel Reply