Hurt vs. Injured

Let’s play pretend.  Pretend there is a team of people working on a web project together.  The team has reached the very end of the build and is hoping to get it launched soon.  Suddenly, one sector of the team decides they don’t like the way something looks and proposes a change.   Making the change might make the product look nicer but it won’t affect the way it works.  Nothing is broken – it’s just not pretty.  With deadlines looming, do you make the change?I don’t, although there’s no question the final product might be better to the eye.  The hardest thing as you’re creating something new is to say “that’s it” and stop tweaking.  At that point, the team needs to be focused on what’s broken vs. what’s nice.  It’s the old “are you hurt or are you injured” thing.  Everyone plays hurt but if you’re injured it needs attention.  Same thing on most projects.  They can always be made prettier but that may not make them any better.  However, if something is wrong – it’s not working, a number is off – something fundamental to the job – then you need to deal with it immediately.   People tend sometimes to get hung up in “nicer” and confuse it with “better.”

The thing is we all know is one of the best things about the web (OK, one of the worst things too) is that nothing is ever “done.”  We’re constantly changing.  In some tech sectors – mobile or software for example, you can’t really make changes on the fly since updates need to be downloaded but that’s more about timing than finality.  It’s hard, therefore, to draw that line – the point at which “fix” is the mantra and “tweak is the next iteration.

Can you make that distinction?  Can your team?