Ironically, you could say I took my time writing this article. It would be even more ironic if you learned that I wrote and published this in one night. But really, I've had this idea in the back of my head for a while and it's been gestating for the better part of the last 2 years.

Speed.

Everywhere I look now I feel like people are living and dying by speed. Speed as the number one metric of success. Speed as the silver bullet for a successful launch, a satisfied stakeholder, a content client, a perfect market fit.

I don't want to misconstrue the sense of importance that velocity has for a tech company. I'm not here to argue about the value of hitting a deadline early, or delivering a product on a tight timeline, both of which I have personally tried and celebrated for.

To me, speed is ultimately misunderstood.

From my experience, people tend to view the velocity of a project in a very one dimensional sense. They will usually fixate on 2 primary questions:

1) Can I get from point A to point B?
2) How long will this take?

For project management I can understand why these would be important questions. I remember having the analogy explained to me early on in my career, that working in a tech company (specifically in a start-up) resulted in placing emphasis on getting something moving early on.

If your ultimate goal was to build a car to sell, it's the idea that your first step shouldn't be to order tires. It should be about building a skateboard, and then a bicycle, and then a motorbike and so on and so forth. The point being that at every significant stage, you have something that is operational for the purpose you originally sought out - the thing you built moves!

Okay great, makes (enough) sense right? Part of me still agrees with this philosophy - for start-ups especially, it's something frequently addressed by the likes of people such as Pieter Levels and Paul Graham. Just push something through as quickly as you can. It can be buggy with limited scope, and overall just barely there, but so long as the core concept works, then you can worry about the rest later.

Fundamentally, I don't think the approach is flawed. What I think is flawed is how it's adopted and practiced by almost everyone else. 

Going back to the car example - to me, there is no point rushing to build a car if it is just going to crash over the finish line, with no one able to put the fire out.

I've watched projects get rushed, with an artificial emphasis placed on speed. It came at the expense of learning opportunities for junior developers, completely shutting down collaborative efforts and team rapport, and overall introducing a needlessly stressful experience for everyone; the management team included.

My philosophy, as you have probably guessed by now, is really the polar opposite to this.  Go slow to go fast.

Building a strong foundation for a project, cutting only necessary corners and not at the expense of quality, will result in a much more stable experience for developers, managers and clients. In some cases, it may even accelerate the velocity of a project in it's later stages of development.

Sure, you could argue that even if you took your time, what's to say you wouldn't just reach the same outcome? Though I can't deny that some projects are still bound to crash, taking time to go slow will more often than not ensure you build a car rather than a torpedo with wheels.

It might sound like I adopted such a philosophy just to be a pretentious contrarian, but in reality, I had a background in quality assurance before I ever became a developer. My first real job in tech (second if you count me working at a second-hand iPhone store) had me doing QA at one of the largest tech companies in New Zealand.

As much as I disliked doing it, I learned to prioritise quality first before anything else. Even if it created tensions between myself and developers, or if I held up a project.

Managers can be upset that things aren't going as quickly as they could be - that the arbitrary timeline they mocked up isn't being met exactly per each milestone. That there aren't always hand-wrapped deliverables to send to clients at the end of every sprint.

For a product, quality was the universal language that everyone understood - developer, manager, executives, clients, end-users. In the same light - if a product sucked, everyone knew it sucked. Even the developers who might argue against criticisms of their sub-standard code would only really be fooling themselves - the quality of the product would reveal it.

After I shifted across to become a developer at a start-up, context switching with both jobs and environments, I tried to keep that same mindset regarding quality.

Yes, initially things will be slower. The starting out always is, because you need to make sure you get it right. But that's just it, the starting out. Everyone gets stuck thinking about the 2 questions, and they fail to see the bigger picture.

Sometimes with a start-up you will feel like the writing is on the wall - and maybe that's true, but it's up to you if you want to read it.




