Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Finishing what you start makes teams more productive and predictable

lucasfcosta.com

Post reply on HN
Print view View original

91–100 of 165 posts

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

#91

Post by throw1234651234 »

Archelaos wrote: post #55
coderintherye wrote: post #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. Bu…

But how do you encourage people for difficult tasks? It is easy to commit myself to correct a particular spelling in a lable by tomorrow. But to fix the indeterministic bug that crashes our top client's server every now and then?

Nothing. There is also nothing to encourage people from not taking forever. This metric worked well on my team until I got people who game it by pulling easier tickets and then sitting on them for a week. We still use the approach though. No approach survives a bad team. I could implement draconian rules, but that would just hamper the productive people.

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

#92

Post by barking_biscuit »

jraph wrote: post #23
jmathai wrote: 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…

I hate having to ship features when I just want to work on improving reliability, doing upgrades, improving DX and clearing all the crap out of the way that's preventing us from otherwise shipping.

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

#93

Post by methyl »

jmathai wrote: 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…

Not only shipping, but ideally shipping and receiving feedback about it. Feedback shows people care. It's not really motivator to ship something that people don't care about, or worse, don't use at all. It's shipping useful stuff that motivates people.

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

#94

Post by throw1234651234 »

thejosh wrote: post #34
jmathai wrote: 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…

Yep. And if nobody actually cares about the feature like everyone thought they would, great we didn't waste time. If they hate it (usually through feature flags of product trials), and work needs to be done, simply flip the flag back off. It's a great way to do small-medium features.

No it's not. Everyone who loves feature flags has never done serious work. The amount of extra work / redundant code that has to be done to accommodate different DB schemas / DTOs in addition to the "lol feature flag" on the front end is absurd.

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

#95

Post by thejosh »

throw1234651234 wrote: post #94
thejosh wrote: post #34

Earlier quoted context omitted.

Yep. And if nobody actually cares about the feature like everyone thought they would, great we didn't waste time. If they hate it (usually through feature flags of product trials), and work needs to be done, simply flip the flag back off. It's a great way to do small-medium features.

No it's not. Everyone who loves feature flags has never done serious work. The amount of extra work / redundant code that has to be done to accommodate different DB schemas / DTOs in addition to the "lol feature flag" on the front end is absurd.

If your feature flags are behind such complexity you have a bigger problem than feature flags.

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

#96

Post by ISL »

barking_biscuit wrote: post #92
jraph wrote: post #23

Earlier quoted context omitted.

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…

I hate having to ship features when I just want to work on improving reliability, doing upgrades, improving DX and clearing all the crap out of the way that's preventing us from otherwise shipping.

In this context, a completed upgrade or cleanup would count as "shipping".

The article's author seems to primarily emphasize serializing processes so that incremental progress is readily evident to everyone and the organization can reap early wins from the first-shipped results.

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

#97

Post by throw1234651234 »

thejosh wrote: post #95
throw1234651234 wrote: post #94

Earlier quoted context omitted.

No it's not. Everyone who loves feature flags has never done serious work. The amount of extra work / redundant code that has to be done to accommodate different DB schemas / DTOs in addition to the "lol feature flag" on the front end is absurd.

If your feature flags are behind such complexity you have a bigger problem than feature flags.

Note "serious work". If you are hiding a banner, an extra button that calls a service method used elsewhere, some text, etc - feature flag away.

Real world problems tend to be, at the very least, "add some new fields to the form" - at which point you are messing with DB schemas OR following bad practices like making fields that should have no business being nullable accept nulls because "who knows if the feature flag is on". This quickly destroys normalization and data consistency.

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

#98

Post by grayclhn »

kqr wrote: post #27
coderintherye wrote: post #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. Bu…

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

That can be good. The number of times I’ve actually wound up doing something I was “definitely going to do” is way less than 100%.

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

#99

Post by civilized »

cjmcqueen wrote: post #73
Heleana wrote: post #69

I believe that those first explanations and graphics are missing an important aspect. The step in the burger-cooking process that takes the longest is the grilling step, during which the cook does nothing but wait for the burgers to finish cooking. The cook cannot speed up the process by focusing on only one burger at a time instead of both. Even without all of the math on batch processing that is presented later in…

Do you think you're considering the burger metaphor, ie the type of task, and not letting the point of the article stay front and center? I think we can agree that not all development tasks are the same, but I think the premise of first in first out is better than large bulk concurrent tasks, which I thought was the premise of the .

We shouldn't get fixated on it but it's worth noting that the metaphor is awful and it's weird that the author doesn't see that.

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

#100

Post by mind-blight »

valenterry wrote: post #49
baby wrote: post #47

Earlier quoted context omitted.

I think you need a way to have deadlines, without that you can easily fall into over engineering or completing other unrelated tasks.

I think for junior developers that might be true. Does the name connect? :)

I've worked with (and been a) staff engineers who have fallen into the same trap. Over engineering is something that we need to constantly be cognizant of because it's often dependant on scope.

E.g. are microservices over engineering? If you have 1 user now, and only expect 100 total users over the next 2 years, probably. If you're running AWS, definitely not. Everything in between becomes a grey area that requires thoughtful architecture to decide on the right approach, and even very experienced people will make the wrong calls

Post reply on HN