How and Why to Reduce Your Scope

First Published: January 15, 2021
Hi! 👋 This article has been revised and expanded as a chapter of the Developer Microskills Guide to Tiny Experiments. It's available as an ebook and audio book! 🎉

One of the steps of the Tiny Experiments framework is Reducing Your Scope 🔬. Once you Just Pick Something 🎯 you want to work on, whether it's a blog article, a new language to learn, or a health goal, you need to trim the dream down into an MVP you can deliver. Today I want to dive a little deeper into how to do this and why it's so important.

Why Reducing Scope Works

When I was in high school, I had this part-time percussion instructor named Jason. Jason was a recent UCF grad and drummed at Disney in a group called The Jamitors (think Stomp: drumming on trash cans). He listened to Phish, was in a band, and was really talented, so 14 year old Sam basically thought he was the coolest guy ever. One of the first times he worked with my percussion section, he played us this incredible piece on the marimba. It had all of these lightning fast sections in it and we were all blown away.

"This is the first piece we're going to work on," he said. "I'm going to teach you how to play this."

We were in shock. None of us had ever played something that difficult or fast. He then taught us a technique for practicing that changed my life as a musician:

  1. Take a tiny chunk of the piece (a few measures, which is really just a few seconds of music)
  2. Slow it down so you can practice it correctly over and over again
  3. Gradually speed it up as you learn it
  4. Move to the next few measures and repeat

Eventually you can start stringing together the different sections, practicing two of them together, then three, then four, until you can play the whole piece.

I felt like he had just unlocked the secrets of the universe. I latched onto this technique and my proficiency skyrocketed. Playing fast pieces and solos on the snare drum, keyboard, or marimba kind of became my thing in high school. I would take on pieces that were much more difficult than most of my peers and spend hours breaking them down section by section.

If you're a musician or an athlete, you've probably had a similar experience at some point in your life. Maybe you're neither a musician nor athlete but you've had to do physical therapy for an injury. A few years ago I threw out my back (ah, the joys of your 30s) and had to go to PT. The (painful) lesson that the therapist drilled into my head was that correct movements are infinitely more important than fast movements when you are learning or correcting a problem. It worked, too: months of daily slow, exhausting, but correct exercises strengthened my muscles and healed my injury.

So, moving slowly and deliberately is one element of learning effectively.

At the same time, as I said in my talk on building a learning system, swift action is a key to transformation. Doing something challenging quickly is a way to shut off the overthinking part of your brain and accomplish something. Think about lifting a heavy weight or performing in a match. You don't have time to second guess yourself because there are real consequences of wasting time and mental energy on anything but your physical performance. We can emulate that in our work with some well-placed accountability and scoping a deliverable correctly.

The magic of reducing your scope is that it enables you to move quickly and complete something while only taking on what you can do well.

How to Scope a Project

How do you find that balance of simultaneously moving fast but doing a good job? Reduce the scope to match your skill and experience level.

Some examples:

  • If your dream is to have a successful technical blog but you've never written consistently, reducing your scope might just mean regular posts of a few hundred words.
  • If your dream is to learn a new programming language, reducing your scope might mean building a very small "hello world" app.
  • If your dream is to create your first video course but you've never recorded any screencasts, reducing your scope might mean recording your first 30 second video.

Notice that all of these examples have concrete deliverables: a blog post, a small app, and a video. It's up to you to impose the "definition of done" and it will vary by the medium.

The key is to make these MVPs just challenging enough to push you while small enough to be able to complete the task in a short period of time. "Challenging enough" is just enough to make you feel nervous without paralyzing you. Take what sounds easy and add another 10% to it.

What's a short period of time? For me, a few days works best, because usually with each project there is some amount of admin and marketing work that has to pair with the creative work of coding, writing, or recording. It also means that, even with other work in the mix, I can generally complete the project in a week. If I'm going to do something regularly, like write a weekly article, this time limit is a necessity.

If you have no clue how much time something will take, do an experiment where you block off no more than 10 hours in a week to work on a project and see how far you get. Then, scale that back by a third to account for admin and marketing work that might get mixed in (things like publishing, deploying, tweeting, cross-posting, optimizing for SEO, etc.).

As you build more skill and experience, you'll be able to scale the amount you can ship in a few days. You'll get better at the creative side and you'll also get better at building systems around the steps that are time-consuming in the beginning. Don't try to optimize too quickly, though. It takes time to identify what exactly you need to automate. If you over-engineer a solution, it will likely cause bigger problems.

What about bigger projects like a book or a course? Naturally you can't get those done in just a few days, but you can use this same process to create sub-projects and deliverables, whether that's a chapter, a module, or a piece of development work. Instead of having a big looming endless project called "Make video course," break it down into smaller projects like "Record first module," "Build landing page," and "Build sample project."

Top Takeaways

Here are the top take-aways for Reducing Your Scope 🔬:

  • Have a concrete deliverable so you can know it's finished
  • Optimize for quality over speed or size (do it as slowly as it takes to do it right)
  • Reduce the scope to something you can execute well in a few days or less
  • Make the MVP about 10% more challenging than feels comfortable to push your limits

From here, you're ready to plan your first Tiny Experiment. We'll dig deeper on that in a future article, but feel free to review the overview article on how to finish what you start in the meantime.

As always, let me know if this stuff is working for you or if you have any questions.

This article began its life as an issue of the Developer Microskills Newsletter. Each week, I send out a practical, actionable way to improve as a developer and developer advocate. Sign up below!

Project list gathering dust? 👀

Drop me a line below so I can send you the Tiny Experiments framework and worksheet. It's a simple process to help you finish what you start. You'll also join over 2100 other devs and dev advocates on the Developer Microskills newsletter. In each issue of Developer Microskills, I share a practical, actionable way to grow in your career or be more effective in your work. No motivational speeches, no hand-waving, and no spam, but also no infuriating sense of self-importance that plagues so much career and productivity advice out there.

Sam Julien © 2015 - Present