Live data from Hacker News

Finishing what you start makes teams more productive and predictable

lucasfcosta.com

21–30 of 165 posts

Re: Finishing what you start makes teams more productive and predictable

#21
post #7

Article relies on a non-sequitur assumption that you should work on an entire feature start-to-finish without interruption. What management ought to do is to split feature work into tasks of smallest granularity as possible, then schedule only those of highest priority. This is what actually reduces batch sizes. Then deciding to prioritize the work to finish a feature instead of new work for a different feature becom…

> If Development doesn't deliver business value because Product can't stick to a coherent feature strategy, that's Product's fault, not Development's.

It's only not your problem too if you like working for failed companies.

Re: Finishing what you start makes teams more productive and predictable

#22
This is why when leading an engineering org I narrowed down to one metric:

Committed to Completed Ratio

It encourages completing things and only committing to what you can complete.

It's legible, easy to understand by engineering, product, and management, pointless to game, and positively reinforces completion. It's quite difficult to accurately predict when a complete feature will ship, let alone a whole product. But, if one breaks down a feature into its legible constituent components and then commits to completing just what is within that (which also necessitates any required communication to arrive at understanding the requirements) then over time you can get quite good at predicting what you will be able to get done in a sprint and better at only committing to what you believe you can actually complete.

Re: Finishing what you start makes teams more productive and predictable

#23
post #17

In my experience on small teams that I've been on - a key motivator for people is shipping products and features. The sooner and more frequently you can do this the more positive reinforcement there is for the entire team - not to mention reduced risk of something never making it to the target users. Teams that have figured out the optimal way to get product and features into the hands of users as quickly as possible…

Releasing is great. Unused work is quite sad.

A big condition for motivation though is if people are not pressured to rush features.

Being in a rush does not work long term and not being happy with the quality of the work done is very demotivating and impairs the sense of meaning. Micromanagement too.

Personally, the two week sprints and daily stand-ups did this to me in my previous job, but I can see they could be a source of motivation for others. So, how work is organized and managed is really important too and depends on the people in the team.

Re: Finishing what you start makes teams more productive and predictable

#24

This is why when leading an engineering org I narrowed down to one metric: Committed to Completed Ratio It encourages completing things and only committing to what you can complete. It's legible, easy to understand by engineering, product, and management, pointless to game, and positively reinforces completion. It's quite difficult to accurately predict when a complete feature will ship, let alone a whole product. Bu…

Sounds like a book in the making. Would love to read this.

Re: Finishing what you start makes teams more productive and predictable

#25

This is why when leading an engineering org I narrowed down to one metric: Committed to Completed Ratio It encourages completing things and only committing to what you can complete. It's legible, easy to understand by engineering, product, and management, pointless to game, and positively reinforces completion. It's quite difficult to accurately predict when a complete feature will ship, let alone a whole product. Bu…

You get a pretty good ratio by doing very little using only that metric.

Re: Finishing what you start makes teams more productive and predictable

#27

This is why when leading an engineering org I narrowed down to one metric: Committed to Completed Ratio It encourages completing things and only committing to what you can complete. It's legible, easy to understand by engineering, product, and management, pointless to game, and positively reinforces completion. It's quite difficult to accurately predict when a complete feature will ship, let alone a whole product. Bu…

Don't people start to go, "oh, we're definitely going to do this, we just haven't committed yet"?

Re: Finishing what you start makes teams more productive and predictable

#28
post #5

Fact is, a team with five people working on five independent tasks may be able to proceed at high throughput, because of the cost of coordination when you assign multiple engineers to the same task. That is, if you have chef A making a burger, and chef B making a salad, and chef C making a cake, then they can all go at full speed because they're using different parts of the kitchen and don't need to coordinate with e…

i think we're talking about giving a single engineer multiple tasks.

The article is definitely talking about teams. It says "teams" lots of times.

Re: Finishing what you start makes teams more productive and predictable

#29
post #25

This is why when leading an engineering org I narrowed down to one metric: Committed to Completed Ratio It encourages completing things and only committing to what you can complete. It's legible, easy to understand by engineering, product, and management, pointless to game, and positively reinforces completion. It's quite difficult to accurately predict when a complete feature will ship, let alone a whole product. Bu…

You get a pretty good ratio by doing very little using only that metric.

That's a problem with pretty much any ratio

Re: Finishing what you start makes teams more productive and predictable

#30
post #25

This is why when leading an engineering org I narrowed down to one metric: Committed to Completed Ratio It encourages completing things and only committing to what you can complete. It's legible, easy to understand by engineering, product, and management, pointless to game, and positively reinforces completion. It's quite difficult to accurately predict when a complete feature will ship, let alone a whole product. Bu…

You get a pretty good ratio by doing very little using only that metric.

That's a fair criticism for certain contexts. Most people I've worked with desire to do well and to feel good about their accomplishments. In those sorts of teams, this works. It would likely not work as well in an environment where people were just hoping to do the minimum possible.
Post reply on HN