"Stop starting, start finishing", one of the best advice I received in my professional career

English Forum Community Tips Forum Leader tips
1

One of the best pieces of advice I ever got came years ago from a colleague who told me: “stop starting, start finishing”.

He was a scrum master, I was a web developer, and at the time I prided myself on juggling many things at once. I could have 15 bugs open: a few already deployed, some in review, and the rest in progress on my screen. I thought I was being productive, but in reality I was flooding my team with code reviews. They had to stop their own work to review mine, which slowed everyone down.

That’s when he told me: don’t start new things, finish what you already started. Or even better, help someone else finish what they’re working on.

This went against how I was wired. My instinct was always to take a big problem, break it into steps, and publish each step as soon as I was done. The issue is I’d get distracted and spread myself too thin, which meant I had a lot of problems “in progress” but not a lot actually finished.

I still catch myself doing this today. What I’m trying to practice instead is writing down the full list of things required to actually make a problem disappear. What’s the definition of done? What’s the acceptable outcome? And then I keep my head down until that problem is fully solved before moving on.

It’s harder for me, but it’s also far more efficient. Once something is finished, it’s really finished, and that frees me up to focus on the next thing. Tools like Asana help me a lot here by letting me break problems into subtasks so I can see progress and know when it’s truly done.

Bastien, Asana Expert
i.DO (Asana Partner: Services & Licenses)

15 Likes
2

One other thing that I use as well is the idea that “90% done is 90% incomplete”…

it helps me (personally) to complete tasks, and like you, realizing that I need to understand the outcome I want and better refining my definition of done.

3

Could also be used by someone to tell that something isn’t finished, so I am tempted to say that “90% done can often be considered complete” :rofl:

1 Like
4

LOL - Absolutely… which is why a “definition of done” and clear understanding of the desired outcomes (acceptance criteria) is SO important. :grinning_face:

5

But with a lot of daily tasks, you can’t be as strict as having a definition of done. And I think some people won’t stop until they covered all their basis, when I fact you can probably stop at “good enough”, and revisit later

6

Shout out to the scrum masters :saluting_face: . I come from a design background, and my scrum master drilled one rule into us, stick to the brief and never try to impress the user department. User departments often tried to sneak in extra requests after the work was done. Our rule was simple. If it met the brief, it was marked complete, and anything new moved to phase two. She wasn’t popular for it.

1 Like
7

That’s a great rule. Let me finish and deploy V1. And let’s create a V2 that will go to the backlog for prioritisation.

1 Like
8

The approach you are now taking has been my own personal default, but I have the opposite problem because I then tend to obsess over the thing I started to the detriment of moving on to something else. That whole “perfectionism is the enemy of the essential” thing hits me hard.