4 ms·

This article touches on it, the _why_ of the process, and Bezos put it really nicely in one of his shareholder letters. "The process becomes the proxy for the

by jatins 5y ago

This article touches on it, the _why_ of the process, and Bezos put it really nicely in one of his shareholder letters. "The process becomes the proxy for the result you want. You stop looking at outcomes and just make sure you're doing the process right." People change, organisation evolves and the process becomes the goal -- and that's when the process falls apart. Which is why I have a bit of aversion towards strictly enforced processes. Good organisations will seek feedback on processes, encourage you to ask questions, and _sometimes_ old processes will get reverted because they are not applicable anymore but because of inherent inertia it's always a little too late.

kqr 5y ago
I'd make that "sometimes" stronger -- if you're not failing often, you're not trying enough things! That goes also for process change. Processes should be invented by the people who use them, and they should continuously evaluate their appropriateness and suggest adding, removing, reordering, or changing steps based on their day-to-day experience. These suggestions should run in limited trials and then either reverted or made permanent. In the ideal case, you run a new experiment every week (or if the process is used more rarely, perhaps every quarter.) ---- Also note the critical distinction: it should not be "the organisation" that creates processes and seeks feedback on them. It should be the people the process applies to who creates it and they will naturally get feedback as part of their job executing on it. Think of it not as "regulation" (an authoritative body demands something) but more as "standardisation" (the involved people come together to agree on the best way to do something, based on their collective experience.)
- allisdust 5y ago
  The only thing worse than a strict process is a quickly changing process. Because then people will be forced to keep track of the changes and it becomes even more difficult to become compliant. Ideal process would include the feedback from day 1 and iterate either based on demand or at fixed intervals placed as far as possible.
  - pablok2 5y ago
    Moving targets make 9-5 work more like entrepreneurship in the sense that you have strict processes that are common-sense (effectively) but to stand out you have to be creative at the process level on top of being creative at a context-specific job level too.
rewgs 5y ago
You just very clearly articulated something I’ve not been able to put words to.
bryanrasmussen 5y ago
>The process becomes the proxy for the result you want. this is really common for legally mandated process, and perhaps even to be wished for by the organization - hey we followed the process you guys set up, what do you mean all this money we got is dirty?
mellavora 5y ago
Friend of my worked in banking for many years. Came up with a clear process and policy for illiquid FX trades. Part of the policy was that the counterparty banks needed to be separate from the FX currency pairs. People in another branch applied the process to trading rubles. Made a ton of money. Until a crisis hit; turns out the counterparty banks were all Russian. Position went to zero basically immediately, all prior profits zapped, and some uncomfortable conversations occured. The other branch was upset, they thought they'd followed the process. But they'd missed an important aspect of the policy doc. Point is: Sometimes short-term results get favored over process, this can be equally dangerous.
hef19898 5y ago
The amazing about that quote is tgat Amazon's logistics ops are the most standardized I've seen so far. There were signes of prioritizing the process over the goal, as Bezo's wrote. And still the goal always won out in the end. It's those small things that make Amazon the company it is. All that is only valid for my time there, no idea how things are now.
edelans 5y ago
there is also this gold nugget from Steve jobs (there is no date, late 80s ?): https://www.youtube.com/watch?v=l4dCJJFuMsE https://www.youtube.com/watch?v=l4dCJJFuMsE >"Companies get confused. When they start getting bigger, they wanna replicate their initial success, and a lot of them think somehow there is some magic in the process of how that success was created. So they try to institutionalize process accross the company, and before very long, people get very confused that the process is the content. And that's ultimately the downfall of IBM : IBM has the best process people in the world, they just forgot about the content." [...] >"In my career, I found that the best people are the ones really understanding the content, and they are a pain in the butt to manage, but you put up with it bc they are so great at the content. And that's what makes great product : it's not process, it's content."
- rvense 5y ago
  > no date I think this is from an interview made for the documentary Triumph of the Nerds, so 1995. https://www.youtube.com/watch?v=rDqQcmVqAm4 https://www.youtube.com/watch?v=rDqQcmVqAm4
- ignoramous 5y ago
  Very similar to what I read recently: > ...the question of repeatable processes versus the flash of brilliance. > In many cases, there isn't much of a compromise between the two. A really great novel is never written using a repeatable process (although pretty good mass-produced junk fiction can be and is). Meanwhile, a widget factory runs on repeatable processes, and doesn't require much brilliance once it gets going. (Hopefully there was some brilliance in the original widget design.) > ...the never-ending conflict between "Software Engineering" and "Computer Science." Software Engineering claims that software can be created faster, better, and more reliably if you can just define repeatable processes and hire a bunch of code monkeys to implement those processes. For some things, like banking applications and warehouse management software, it works: well, at least it works better than trying to do the same thing without your repeatable processes. Computer Science, on the other hand, is all about the flashes of brilliance and the "aha!" moments. > ... > Unfortunately, it seems that two totally different social structures are needed to produce repeatability versus brilliant insight. A structure that encourages repeatability will stifle creative insight; but a structure that encourages creativity produces non-repeatable results, almost by definition. > ...I do know the form of the solution: you want a process that repeatably produces brilliant results. If you could do that, you would be unstoppable.* More compromises (2006), https://archive.is/EEMxl https://archive.is/EEMxl | https://apenwarr.ca/log/20060210 https://apenwarr.ca/log/20060210
mfrommil 5y ago
It depends on what the process is for. Regulatory / legal compliance? Solid process = good Non-customer-facing repeatable operations? Solid process = good Financial controls (with the right level of flexibility for smaller/quick decisions to be made)? Process = good Restricting creative/knowledge worker teams - whether design, product, marketing, engineering - with over-burdensome "process for the sake of the process" = quick way to lose good talent and kill good ideas before they come to life

by jatins 5y ago

kqr 5y ago

I'd make that "sometimes" stronger -- if you're not failing often, you're not trying enough things! That goes also for process change. Processes should be invented by the people who use them, and they should continuously evaluate their appropriateness and suggest adding, removing, reordering, or changing steps based on their day-to-day experience. These suggestions should run in limited trials and then either reverted or made permanent. In the ideal case, you run a new experiment every week (or if the process is used more rarely, perhaps every quarter.) ---- Also note the critical distinction: it should not be "the organisation" that creates processes and seeks feedback on them. It should be the people the process applies to who creates it and they will naturally get feedback as part of their job executing on it. Think of it not as "regulation" (an authoritative body demands something) but more as "standardisation" (the involved people come together to agree on the best way to do something, based on their collective experience.)

allisdust 5y ago
The only thing worse than a strict process is a quickly changing process. Because then people will be forced to keep track of the changes and it becomes even more difficult to become compliant. Ideal process would include the feedback from day 1 and iterate either based on demand or at fixed intervals placed as far as possible.
- pablok2 5y ago
  Moving targets make 9-5 work more like entrepreneurship in the sense that you have strict processes that are common-sense (effectively) but to stand out you have to be creative at the process level on top of being creative at a context-specific job level too.

rewgs 5y ago

You just very clearly articulated something I’ve not been able to put words to.

bryanrasmussen 5y ago

>The process becomes the proxy for the result you want. this is really common for legally mandated process, and perhaps even to be wished for by the organization - hey we followed the process you guys set up, what do you mean all this money we got is dirty?

mellavora 5y ago

Friend of my worked in banking for many years. Came up with a clear process and policy for illiquid FX trades. Part of the policy was that the counterparty banks needed to be separate from the FX currency pairs. People in another branch applied the process to trading rubles. Made a ton of money. Until a crisis hit; turns out the counterparty banks were all Russian. Position went to zero basically immediately, all prior profits zapped, and some uncomfortable conversations occured. The other branch was upset, they thought they'd followed the process. But they'd missed an important aspect of the policy doc. Point is: Sometimes short-term results get favored over process, this can be equally dangerous.

hef19898 5y ago

The amazing about that quote is tgat Amazon's logistics ops are the most standardized I've seen so far. There were signes of prioritizing the process over the goal, as Bezo's wrote. And still the goal always won out in the end. It's those small things that make Amazon the company it is. All that is only valid for my time there, no idea how things are now.

edelans 5y ago

there is also this gold nugget from Steve jobs (there is no date, late 80s ?): https://www.youtube.com/watch?v=l4dCJJFuMsE https://www.youtube.com/watch?v=l4dCJJFuMsE >"Companies get confused. When they start getting bigger, they wanna replicate their initial success, and a lot of them think somehow there is some magic in the process of how that success was created. So they try to institutionalize process accross the company, and before very long, people get very confused that the process is the content. And that's ultimately the downfall of IBM : IBM has the best process people in the world, they just forgot about the content." [...] >"In my career, I found that the best people are the ones really understanding the content, and they are a pain in the butt to manage, but you put up with it bc they are so great at the content. And that's what makes great product : it's not process, it's content."

rvense 5y ago
> no date I think this is from an interview made for the documentary Triumph of the Nerds, so 1995. https://www.youtube.com/watch?v=rDqQcmVqAm4 https://www.youtube.com/watch?v=rDqQcmVqAm4
ignoramous 5y ago
Very similar to what I read recently: > ...the question of repeatable processes versus the flash of brilliance. > In many cases, there isn't much of a compromise between the two. A really great novel is never written using a repeatable process (although pretty good mass-produced junk fiction can be and is). Meanwhile, a widget factory runs on repeatable processes, and doesn't require much brilliance once it gets going. (Hopefully there was some brilliance in the original widget design.) > ...the never-ending conflict between "Software Engineering" and "Computer Science." Software Engineering claims that software can be created faster, better, and more reliably if you can just define repeatable processes and hire a bunch of code monkeys to implement those processes. For some things, like banking applications and warehouse management software, it works: well, at least it works better than trying to do the same thing without your repeatable processes. Computer Science, on the other hand, is all about the flashes of brilliance and the "aha!" moments. > ... > Unfortunately, it seems that two totally different social structures are needed to produce repeatability versus brilliant insight. A structure that encourages repeatability will stifle creative insight; but a structure that encourages creativity produces non-repeatable results, almost by definition. > ...I do know the form of the solution: you want a process that repeatably produces brilliant results. If you could do that, you would be unstoppable.* More compromises (2006), https://archive.is/EEMxl https://archive.is/EEMxl | https://apenwarr.ca/log/20060210 https://apenwarr.ca/log/20060210

mfrommil 5y ago

It depends on what the process is for. Regulatory / legal compliance? Solid process = good Non-customer-facing repeatable operations? Solid process = good Financial controls (with the right level of flexibility for smaller/quick decisions to be made)? Process = good Restricting creative/knowledge worker teams - whether design, product, marketing, engineering - with over-burdensome "process for the sake of the process" = quick way to lose good talent and kill good ideas before they come to life