Finishing what you start makes teams more productive and predictable

Teams that have figured out the optimal way to get product and features into the hands of users as quickly as possible are the happiest teams because it's evidence that they're working together efficiently to meet their shared goals.

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.

This could be a reasonable assumption if you're very good at adjusting scope, but I would be skeptical unless you have measured it and have the numbers to prove that in practise, tasks indeed turn out to be roughly the same size (±20 % or whatever -- I don't know the exact threshold.)

Why this matters is that under cheap context switches and even modest task size variability, it's -- surprisingly -- a performant queuing policy to pre-empt the currently processing task to handle every incoming task. The intuition behind this is that if a task is still processing when a new one comes in, it's likely to be a "big" task, and it's worth letting small tasks ahead in line. Reduces mean response time.

Of course, this could all be moot anyway because context switches are certainly not cheap for software engineers. I just thought I should mention it for nuance. Rules of thumb only get you so far, at some point you have to more accurately model the situation and simulate.

I still agree with the idea teams should do one thing at a time in general, but if you are going to do anything in parallel, it makes most sense to do other work when waiting for something to complete (as in the grilling step in this example)

I keep showing that to people, never gets old https://www.youtube.com/watch?v=CostXs2p6r0

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 each other much. Individuals pay for context switches, but teams can assign different tasks to different team members.

Or maybe I don't understand the point the article is trying to make here. It seems really obfuscated with metaphors involving burgers.

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 becomes a matter of discipline, not process. This is important because it allows management to stop throwing good money after bad on features that the business decided that they don't actually want anymore.

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.

I also find people are twisting definition of done to make it look as-if it's over. Something being coded usually isn't done. It still needs to be tested which is the labour intensive task. Something being tested isn't done, it must be shipped and released to production. Code in production still isn't done. It must work and be performant enough, might need more logs, might need more monitoring. Last but not least it must get into the hands of the users who give the final word. But even then it might not be completely finished.

Multi-tasking has exponentially greater impact on performance the greater the complexity of the task. Most people just don’t find themselves doing these kinds of complex tasks on a daily basis. This is why coming up with a simple example that lay-people can understand is so hard. Simple examples don’t pass their sniff-test. It is obvious to anyone thinking about it that I can make two burgers simultaneously and it only adds a fraction to the overall time. This is because the complexity of the task is extremely simple. In reality it would add seconds, not minutes.

However, once you ramp up the complexity of the task this penalty does approach 1 to 1, or greater. It is obvious to anyone that having to do a heart transplant while also doing your taxes at the same time would require longer than either task individually. An example like that is also easily dismissed because it is so far-fetched.

I find that to really impress on people the penalty involved requires an example that is personal to them. If you can find some complex tasks that they do even rarely and have them envision doing them simultaneously, then they are more likely to buy into the idea. Let’s be honest, most people don’t find themselves in this situation like programmers do because of the deep thinking that programming requires, but if you search hard enough you can usually come up with some personal examples for people. If the person you are trying to impress is important enough in your life (spouse, boss, etc), then it is worth the effort to find some individual examples.

This is why software engineers should be banned from writing about anything outside their very narrow domain (and I say that as a software person).

There's context switching when working on different features, sure. But there's context switching when working on different parts of the burger, too. Slicing two buns is faster than slicing one bun, then coming back from doing something else and slicing another.

There's context switching in both scenarios. Heck, switching between writing a spec and working on the implementation is a context switch too. The switch between features is just generally more significant than the one between the different phases of working on the same feature compared to the steps of working on a burger.

Heck, this also completely ignores that the chef likely doesn't ONLY produce burgers and even when they do not every burger will necessarily be the same. In fast food restaurants you'll actually see chefs do some steps in parallel (e.g. slice all the buns) and some sequentially. Additionally they'll often optimize to finish all items in an order in the same timeframe -- in all likelihood you're not a complete prick and actually want your friends to be able to join you for lunch rather than staring at you for 4-8 minutes while you eat your burger all alone.

The analogy is not just simplified, it's completely ficticious to the point of bearing no resemblence to the actual process it tries to use as an analogy. It doesn't provide a common ground by referring to something everybody knows, it requires actively ignoring what you may know in order to make its point.

Move along, there is little understanding to acquire from this post.

The result surprised me even though I know intellectually I should have expected it.

If everyday you saw you had 100 more things to do and no matter how much you finish, the list doesn't go down, it's not exactly motivating.

Saying “No” to projects which incur serious liabilities, is just as important as minimizing project scope. Unconstrained sisyphean commitments are a common feature afflicting those with Founder's syndrome, and can have detrimental impact on projects as the intelligent begin to jump ship before it sinks.

Every firm that lives past 1 business cycle will have a project boneyard. ;)

You need to deliver all the meals at once, and you need to prepare all the meals in such a way that they can all be delivered at once.

If you need to deliver 4 hamburgers, you prepare them in batches, and deliver them all at once.

Sending out the order in pieces makes the end result much worse for everyone involved. Which is why it's dangerous to look at delivering features as the end goal. You need to deliver a complete meals.

Sending out a single burger doesn't always make sense.

The difference between real life projects and college projects is that often nobody made the same feature in the same context before. This means that there will be features that will take much longer time, and need to be shifted to the next release or a bin for "complex enough to focus on everything else".

If you do not understand why something like this happens, it may be that you are unaware of the knowledge gains from exploration as opposed to releasing the product.

You just need one great product, and it is okay to throw away ten explorations to make it happen.

I'll set goals small, so success and completion are guaranteed, then raise the bar a bit, on the next one, and so on.

Soon, success and completion become habit, for the team, and the results are amazing. I end up with a team that isn't arrogant, but highly confident, and quite efficient.

"Succeeding" also requires things like careful attention to detail, good testing (and fixing), documentation, and other "boring" stuff. Once that becomes habit, it's just "background noise."

It just takes time, and that is something that seems to be at a premium, these days.

But regular success just feels good. I recommend the practice.

Going through the whole explanation, the base assumption is that tasks are clearly defined, there is few surprises, task pipelines seldom break in the middle because of external factors. Which is the hallmark of a predictable dev environment and by proxy, a productive team.

All the team has to do to increase it output is stop doing the tasks in parallel. Conveniently, there is no real explanation of the status quo, teams must have been really lazy and couldn't think by themselves why they were doing so.

This really feels like one more motivational preacher trying to sell that one weird trick to solve all your problem.

In the weakest definition of "finish what you start", it means "I cleaned my desk, I finished what I started" but the reality is - the only way for this to be "done" is to have no more work and no more desk. The work of maintaining that desk cleanliness is never ending work and herein lies the problems we create for ourselves.

Take the burger example and put it in a system - you're on to the next burger and some shmuck wants it without ketchup and with extra pickles. Then you have to cleanup the burger stand but cleaning up one day won't be the same cleanup as another and sometimes you may have to shutdown to deep clean - it's never done until you forever stop making burgers and close shop.

For me, it's all about mindset. I look at work as rewarding when I never stop learning. The notion of done is what makes people crazy because it's never about the work being done, it's about not want to do the work to begin with and not seeing any value in doing it.

My kids rooms are messy, i say they're lazy, but really they see no value in the work - to them, it's a waste of time. It keeps them from doing other things they would rather do. I laugh when they say they're done cleaning their room because without a doubt, not even a day later, it will be a stink mess again.

Also, context switching... these discussions never make sense because they're always discussed in terms of state as an exception to the system. Your flow state is uniquely you, the system you operate in is complex and dynamic.

I think all to often people put way too many words to paper trying to control complex interactive systems when they should really make them safe and resilient to monitor, observe, anticipate what's next and have the autonomy to make decisions.

That autonomy and decision making and anticipation still requires effort and work - and i'll be honest, some of the best flow state is safely operating in complex dynamic systems while being able to mental model your position in it and have empathy for others - realizing that your model is yours and others will have there's.

Done is imaginary.

https://news.ycombinator.com/item?id=32214809

What's even better? Starting the right things that deserve to be started in the first place.

Efficient !== Effective

Author apparently has never understod 'assembly line' nor knows how such things work.

Of course my analogy doesnt map to code delivery, but neither does his burgers.

Worthless

Nice!

While it is optimal to minimise transactional cost due to context switching in that case, maintaining a constant throughput in that scenario would be sub optimal.

Superb write up, though!