Here’s something you may not know: developing software is a very creative.But developers are not generally included with artists and writers in the category of “creative types?”

I have a theory about why: I think it has everything to do with planning.

Artists and writers are notorious for being free spirits, waiting for the muse to inspire them, and flying by the seat of their pants (even if that’s not true of all artists and writers).

Software developers, however, are a relatively more organised bunch. They work on projects with set goals. They plan.

I see this in the Showcase development team all the time. They’re incredible problem solvers, always coming up with creative solutions for our customers’ and new product features. But they don’t write code willy-nilly or "when the inspiration strikes".
At the most basic level, they think through the issue, make a simple plan to solve it, then set parameters (start date, end date, milestones) to complete it.

It’s a very clean, straightforward way of handling tasks. It's much like the method Marie Kondo teaches in her book The Life-Changing Magic of Tidying Up: The Japanese Art of Decluttering and Organising. She may also have spent some time around software developers.

Marie Kondo’s “Konmari” method involves eliminating clutter and excess with the goal of living a more joyful life. Her six rules of tidying are:

  1. Commit yourself to tidying up.
  2. Imagine your ideal lifestyle.
  3. Finish discarding first.
  4. Tidy by category, not by location.
  5. Follow the right order.
  6. Ask yourself if it sparks joy.Applied to software development, developers keep their tasks simple and uncluttered. They don’t come into the office every day and work on whatever sparks their interest. They work on the task they planned to work on, and see it through to completion before moving on.

Granted, rule #6 (ask yourself if it sparks joy) might not apply to all of their tasks - like fixing bugs - but I know that a fixed bug brings them a lot of joy. I admire the clean and tactical planning approach most developers seem to take — and because I’m a chronic over-planner, I’ve tried to learn from them over the years.

Here's are the top three things I've learned:

1. Simplify Your Plan

I have a tendency to overcomplicate my own planning. In fact, I tend to over-prepare before getting started, turning a simple task into a mountain of a project.

In some cases, this is just a way of delaying work on a task. Maybe it’s a task I’m not excited about, or it feels a bit overwhelming. Or maybe there are just other things I’d rather be working on, so I plan and plan and plan … and procrastinate in getting to the task.

In other cases, I’m overthinking things. I’m making a big deal out of a task that should actually be very quick and easy to tackle.

Does that sound familiar at all?

If so, you might need to simplify your plan too.Here are three ways I can tell I'm overcomplicating something:

  • The task is taking me much longer than I anticipated.
  • At our weekly progress meetings, I have a hard time articulating what progress I've made on the task or project.
  • When I think about the task, I feel anxious.

So how do you simplify a plan? The Konmari method articulates what many developers do so naturally:

  • Commit to finishing the task.
  • Imagine what it will feel like to finish the task.
  • Identify the unnecessary steps you’ve been taking or plan to take.
  • Remove distractions: Focus for blocks of time.
  • Do not add to the task. Stay focused on the basics.
  • If another step or element pops into your head, ask yourself if it’s really necessary.

2. Take the time to plan and prepare for success.

The opposite of over-planning is the rush to implementation. Something I've done more than once, and something I see frequently with new users of Showcase.

Let me share this truth: most software aims to make it easier for you to implement good ideas, but it doesn't come up with the good ideas for you.

If you've had any experience with CRMs, marketing automation tools, newsletter software or POS systems you probably already know what I mean. The software itself is capable of some fantastic stuff but you still need a deep sense of what it is that you want to achieve or produce. The software can't do that thinking for you.

At Showcase we encourage our customers to start with planning when they subscribe to our product. Ideally, we work with them directly to organise and map their content, and collaborate with their team to launch their new showcase smoothly and encourage user adoption.

When we can’t work with our customers directly we offer them this content planning guide. This walks them through the planning process, step-by-step, so their showcase will be a sales-multiplying tool rather than a mess of files that are just as confusing as the tool or process they transitioned away from.

What happens when our customers DON’T plan their showcase content before they start implementing?

Spot the difference?

3. Templates Have Their Place

When developers start planning a new feature, something I've noticed that they commonly do is look for established patterns in other popular software products that our customers use or are very familiar with.

It may be a little thing like analysing the language used in presentations products like Powerpoint - do they use "Files" or "Documents" or "Uploads".

Or it might be something much more significant like comparing the way that LinkedIn and Google present data in their campaign reporting screens to the way that we want to show our data.

Either way, the goal is the same, it's all in service of creating as little friction as possible for our users as they move between software products. Less friction = getting the job done faster!

When a task or project (or undertaking of any kind) feels really big to me, I take a leaf from our developers and I look around for templates and standards to follow.

Using a template can certainly help you check off #5 on Marie Kondo’s list of rules: Follow the right order.

But while templates can have an important place in the planning process, they aren’t the answer to every planning problem. Plus, searching for templates can be an easy way to procrastinate on actually doing the work.

Our copywriter shared with me, “A few years ago I was preparing to write a sales page for a training program I was launching. Sales pages are not something I write frequently, so I spent about four hours looking for a good layout template to run with because I thought it would save me time. When I finally got to writing, though, it only took me about an hour. I literally spent four times the amount of time on that task because I was trying to take a shortcut by using a template.”

So here are are couple of sub-rules for using templates:

  1. Look for templates when you think your task or project is commonly done by others - this should save you time starting from scratch
  2. Set a hard limit on the amount of time you are going to spend looking for a template or you may just defeat the purpose of finding a template at all

Marie Kondo, but for YOU

I have to wonder if our developers are going to think I’m crazy for drawing parallels between their work and Marie Kondo’s tidying-up methodology. But the fact is that a clean, simple, streamlined approach to planning can save most of us a lot of stress in any situation.

From planning a sales meeting agenda, to planning a European vacation, to planning the launch of a new product, remember these three things:

  1. Simplify your plan.
  2. Don’t skip straight to implementation.
  3. Use templates when appropriate, and limit the time you spend looking for them.