Delays are one of the most frustrating realities of growing a business. Here’s how we deal with it.
In late August 2011, I found myself staring at some mockups of what would one day become the first iteration of the Groove homepage, and shaking my head.
I wasn’t unhappy with the design; it looked great to me!
But here I was, reviewing a still-in-production creative exploration, two months after we had planned on having a working site and product with paying customers.
We wouldn’t end up launching for another several months, nearly a year later than we originally hoped.
Some of that was due to inexperience, poor planning and, simply put, bad decisions (that we ended up paying dearly for).
But some of it is an issue that we still deal with, both practically and psychologically: everything takes longer than you think.
Today, our team is stronger than it’s ever been, and we operate at a speed and velocity that puts our early days to shame.
But everything takes longer than you think.
We’ve put workflows and processes in place to keep ourselves moving forward every single day.
But everything takes longer than you think.
I’ve talked to entrepreneurs whose teams are much farther ahead than we are, and they push exponentially more code, and have been for many years.
But everything still takes longer than you think.
This doesn’t just apply to building software. Closing partnership deals, running effective marketing campaigns, designing websites; these all often come with unexpected delays.
Here’s why.
We’re Not as Detail‑Oriented as We Think
Development teams love to think of themselves as master planners.
Many good teams account for each person’s time down to the hour (or less).
But still, when we plan—especially those of us in small businesses with limited resources—we often miss little things that add up.
Especially in the beginning.
Let’s take a feature development project, for example.
We have six full-time developers on our team.
None of them has a specific task they’re responsible for; as we grow and evolve, their energy is spent on its highest-value use that day.
And if we try and plan a feature development project that assumes a certain number of productive hours per week spent on the task at hand, here are just a few of the things that might happen:
- Someone gets sick, or their child gets sick, and they need to take a day or two off.
- A flood of tickets comes in on a particular day or week, and a couple of the developers need to spend more time than usual on them.
- A small production push causes an unanticipated issue with an older feature, and we need to spend a day rolling things back and fixing the problem.
- Someone’s power goes out and they lose a half-day of productivity.
- An out-of-our-control issue happens with our servers or website, and that can’t wait to be fixed.
- A part of the project doesn’t function as planned, and the entire thing gets put on hold for hours or days while we work it out.
These delays, while typically insignificant on their own, can add up to days or weeks added to smaller projects, and weeks or months to larger ones.
I’m not saying that you can’t plan for these delays.
I’m saying that most people don’t.
Being Okay With Not Being Hyper‑Productive
You won’t get 8 hours of 100% productivity from every employee every day.
You simply won’t. People don’t work that way, and little things always get in the way.
And tackling this issue is as much about the practical (getting more productive and efficient as a team) as it is about the psychological: coming to terms with the fact that you’re not going to move as quickly as you think.
Not just in development, but across all fronts.
That doesn’t mean that you should give in and not try. Far from it.
Every single person on our team busts their ass every single week to push Groove forward as quickly and efficiently as possible.
This isn’t about being okay with moving slow.
It’s about understanding reality, and letting that reality lead to constant surprise and disappointment.
Because just like delays can add up, those little disappointments do, too. And the compound effect of little disappointments can make a huge impact on your team’s morale.
Be Honest in Your Project Planning
Many businesses use a point-based approach to project planning, where each employee has an allotted number of “points” (usually one points equals one hour) per week, and those points are spread across a variety of tasks.
We used to do something similar, though we’re moving to a Kanban approach for many reasons (I’ll be writing another post about this soon). Crazy Egg has a good list of project management tools here and all of them have Kanban built right in.
But most businesses who do this are far too optimistic in their estimates. Most employees don’t actually put in 40 “points” in a week; that number is typically much, much closer to 30 in my experience and in the experience of many entrepreneurs I’ve talked to about it.
Being brutally honest with yourself about how much productive time your team actually has will go a long way in getting better and more accurate at project planning.
How to Apply This to Your Business
I’m ambitious, competitive and probably work a lot harder and longer than is healthy.
If you’re reading this blog, there’s a good chance that we have that in common.
I don’t plan to lose that drive, and you shouldn’t either.
But I hope that this post helps you realize that when it comes to project planning, being realistic about your abilities and limitations can be a lot more effective in the long-run than being overly optimistic.
Understand that you won’t be 100% productive all the time.
Understand that most things will probably take longer than you think they will.
And understand that while you should work to minimize those delays, they’re going to happen, and that’s okay.
You can still build a very healthy, profitable business. It just might take a little longer than you think.
