You already know that I think learning — including giving yourself space for learning — is very important.
The second you feel like you’ve mastered your own creativity, you stop learning. – The Good Creative
There is a danger in learning though, and I see designers and developers succumb to it all the time. It’s the danger of the new and shiny. These designers and developers may have an established workflow, but read about a new tool that looks way better than the current ones they’re using. So, they dive right in and add the new tool to their workflow.
Sounds great, right?
Well, it could be. But what I see happen time and time again is that next month the latest and greatest new tool pops on the scene — one that replaces last month’s new tool. Heck, it’s even better than last month’s tool, so the temptation for all of us is to jump right in and change our whole process once again (not wanting to miss out on the newest, bestest tool right?).
[Tweet “Changing tools all the time only ensures you never really learn to use any of them”]
Benefits of change
Here’s the thing: The real benefit of that new tool isn’t realized until you’ve used it for a period of time. The learning curve that comes with implementing a new tool can often cost you more time and be less efficient than sticking with the old tool you’re already comfortable with.
That ramp-up time isn’t earned back until you use the new tool for a while. Switching to another new tool can negate any of the benefit you may have received.
This same principle applies to productivity apps. I get at least one email a week about some new project management application or billing software that promises to be better than anything else around.
Some of these do even look super amazing and possibly worth my time, but I resist the urge to dive in and try them.
Every year, I take time in December to look at my billing tools. I try out a few to see if any of them might solve any issues I have with my current app. Sometimes I find a better solution, but more typically the new thing just has different issues. Occasionally the ‘different issues’ matter less than the current issues, so I make a change.
Slow and steady
Yup, this lesson is the web developer’s version of the tortoise and the hare.
Jumping between new tools every few days simply means you are going to get less done. You’re going to spend all your time learning how each new tool works best.
[Tweet “Stop changing tools and actually ship something”]
I’m not telling you to ignore new tools. Instead, take a measured approach. If you see a new tool, schedule some time to look at it and evaluate it. Move it into your tool chain if it’s going to be beneficial.
Schedule some time each year to evaluate your software tools, and only make a change when you have clear evidence that the new software will solve issues that are big to you.
Don’t go jumping around with your changes. Plan them out and execute them at the proper time.
photo credit: kaptainkobold cc
3 responses to “The Danger in Change”
Don’t show this article to the project/tech managers in big ostrich organizations. They are always resistant to change 🙂
Being resistant to change just for change sake is stupid. Being careful so you don’t chase the shiny is good.
Most of the C-Level execs are resistant to change mainly because they are risk averse and don’t want to blemish their career if something goes wrong.