Slow Thoughts from Dale du Preez

One of the most valuable lessons I’ve learnt while working at Automattic is simple, but not always obvious to follow:

Breaking work down into smaller, incremental steps is incredibly powerful.

Regardless of whether you’re trying to break down a project to support better estimation, or trying to decide what goals a project should have, or simply trying to work out how to make a set of changes to a visual component, understanding what steps you need to take is incredibly helpful in the long run.

The most important aspect of breaking down the work is actually about the process itself: by thinking about the smaller tasks, work items, or interim goals, you enrich your understanding of what work needs to be done, and how it fits together. This is especially valuable for engineers, as we will always claim that we can build a widget or a feature, but it’s when we uncover more details that we can more accurately identify which pieces of the whole are familiar or touch on more unknowns.

I also find that it makes it easier to identify smaller parts of the whole that can be delivered sooner, especially when it comes to user-facing features. I often find that we have a vision for the eventual user experience, but when I understand what smaller changes will go into that eventual experience, I can identify changes that are worth getting to users sooner, even if they aren’t quite where we want to end up.

A warning

Don’t get too deep into the details! Try to break things down into workable items, especially when you have similar things to mimic, but don’t dive too deep into the details of how you’re going to do every single piece. Identify any unknowns and queue up time to dig in later on.

Indirect benefits

There are also plenty of secondary benefits to understanding the goal as a set of smaller steps:

• Smaller, clearer work items that are easier to understand, socialise across a team, and provide estimates for.
  • It’s especially valuable for identifying areas where the team doesn’t have relevant experience or expertise
• Smaller, more tightly scoped changes are easier to build, review, test, and ship to users, often with far less risk of failure
• If you’re measuring or tracking the impact of your changes, it’s often easier to see which changes are driving the impact
• If you’re working on a SaaS or a PaaS, you deliver your initial changes sooner, and are able to incorporate metrics from those changes into your decision-making and remaining work
  • It may take slightly longer overall, but users will have benefited from the changes much sooner, and your end result should have been guided by feedback, usage, and impact.

#engineering #ship-and-iterate #small-steps