You are building too slowly

Posted By on Oct 25, 2011 | 7 comments

When I was a child I played with Lego. If I was at home, I had the leisure of playing with my own Lego, and I could take my time and build an elaborate creation. I would go to meticulous detail in building ships, castles or other buildings. I realized there was a certain serenity to playing my own sandbox at my own pace. When I went to kindergarten, I noticed they had a large box of Lego. When I went to play with it for the first time, I got upset that there were other kids taking blocks I wanted to use. I wasn’t afforded the luxury of taking my time, because if I did, I wouldn’t have the pieces needed to complete what I wanted to build. This is a simple parable but it made me realize that I was building too slowly, and not afforded infinite timelines.

I thought back to this during Democamp, where a company named VidYard built an impressive application in 16 weeks, got funded and are now on the upswing. This example made me realize that if you think you are building something quickly, you probably aren’t and will pay the price for it. The level of competition in the software/web application space has only gotten more intense. The ability of a focused and dedicated team to build something quickly is needed more than ever. What I have come to realize is that zealotry of innovation is powerful. People with a taste for both innovation and building something are hard to stop.

Last week, due to this epiphany, I decided to try to tackle something in one week that would normally take me multiple weeks. I refocused, got team buy-in and went to work. This didn’t come without bumps – the time I would normally take to think out every nuance was not there. I stayed up late and built and tweaked until it was ready. I would argue that a perfect plan with nothing built takes a backseat to something that works that perhaps isn’t perfect. It may sound cliché, but a good plan today is truly better than a great plan later. At the end of the week, I lost a lot of sleep and built out something cool. I didn’t quite hit my timeline, but when I looked back at the week, I saw that my team and I had built a lot and learned a few lessons.

So you want to build something quickly? How do you do it?

  1. Set an unrealistic timeline. How better to start this project? Ask yourself how long it would normally take on this project and cut it in half. Setting an unrealistic timeline does two things: 1) it makes you scramble and 2) if you manage to pull it off you will get a huge amount of wind at your back and it will inspire you to do it again. Even if you miss your mark, you will accomplish a lot in that time because you are working your ass off. Think of Darth Vader in Return of the Jedi. He lands on the incomplete Death Star and basically says this thing will be operational or you have to deal with the emperor. Without some brash ambition and, frankly, a bit of fear, you won’t know how fast you can move.
  2. You need to be 126% committed to building something quickly. What does that mean? It means while you are building it, you need to detach from the outside world. Cut out the distractions (Twitter, Facebook, casual web surfing). As much as we love these things, you need to cut them out. Get your team onside, lay out the parameters and just start building. Reconnect regularly with updates, but focus on moving forward. You need to be willing to sacrifice a little bit of sleep and fun, but you will be happy when you get the results. Distraction is the enemy. I can virtually guarantee that someone else has shared that same idea. It is question of whether you want it more than someone else.
  3. When you’ve finished it, evolve it. Like any good lean agile project, as soon as you are done your project, evolve it. This can’t be a one off; you need to evolve. There are reasons that many agile methodologies use the concept of sprints. Those “sprints” can’t be leisurely strolls. After you are done your sprint take a quick break, re-evaluate what you have built. Determine what mistakes you made, fix them and try it again.

These are the caveats to taking this approach

  1. Whatever you build needs to work – if you build, make it functional.
  2. Whatever you are building needs to scale – If you Frankensteined something together with a sloppy code and approach, it is not going to work.


Going back to my original point, the luxury of building something slowly in this day and age is gone. You will get beaten to the market and beaten because those going to market faster will be able to iterate circles around you. It is time to ask yourself, am I willing to bust my ass to get this done quickly or do I perpetually want to come in second place?



  1. Tis is a great post. Make haste while the sun shine is a lesson to take home. Yes, this post is timely and I’ve got lots of stuff to take home with me. My favourite quote here; “This is a simple parable but it made me realize that I was building too slowly, and not afforded infinite timelines.”

    Good work, Joseph!

    Post a Reply
  2. For small systems (under $1M) I think your points are excellent. There is lots of evidence that you shouldn’t worry a lot about systems in this size range. The chances are that they will be successful. This fits in well with what I understand of your philosophy. Don’t worry, just do it.

    However for systems much over $1M, I think there is danger in this approach. You need to take the time to partition the large system into a number of small systems. For systems in the range of $1M-$3M, this isn’t too difficult and your points are still largely valid.

    Once you exceed $3M or so, you really need to slow the whole process down considerably and do a careful, methodical partitioning. Once you have done this, then you have a set of small (less than $1M) systems with minimal dependencies, and you can apply your approach to those individually. First divide. Then conquer.

    So the bottom line is that I like this approach, but you need to understand its limitations. Without a partnership with a directed partitioning methodology, this approach, while good, is limited to relatively small systems of no more than $1M in size.

    Post a Reply
    • I agree on your point for small and mid size projects. I would turn them into mini projects or the more agile term “sprints”. I think we need to focus more, work harder and try to get more done in a shorter period of time.

      Post a Reply
  3. Great analogy Joe! I learned long ago that I’m not very good at jumping from project to project and keeping a lot of rings spinning at the same time. Not that that stopped my “Bright Shiny Object Syndrome”! But focussed work is easy for me now. This post calls me to the next level of focus – focussing on just one thing for a longer period and devoting all ones resources to the achievement of that project. Thanks!

    Post a Reply
  4. I’ve gone through this again and each time, there seems to be a greater meaning to the precepts of this post. Procrastination and a much delayed outlook in solving a task or running a project often times will enable one beat a deadline. Setting unrealistic deadline, makes one work harder and at this same time, still gives one ample time even if the project is not executed on the unrealistic time! There is is some more time to play with to dot the i’s and cross the t’s.

    I still surmise that this article is timely. And as usual I shall leave with a quote! “It may sound cliché, but a good plan today is truly better than a great plan later.”

    Post a Reply
  5. Oops, I meant to say “will NOT allow one beat a deadline…”

    Post a Reply
  6. Motivating! Thanks Joe! Going to apply this to a few projects I’ve been working on.

    Post a Reply

Submit a Comment

Your email address will not be published. Required fields are marked *