[alexpotato]

One of my favorite stories about processes and documentation:

- Work at a hedge fund

- Every evening, the whole firm "cycles" to start the next trading day

- Step 7 of 18 fails

- I document Step 7 and then show it to a bunch of folks

- I end up having a meeting where I say: "Two things are true: 1. You all agree that Step 7 is incorrectly documented. 2. You all DISAGREE on what Step 7 should be doing"

I love this story as it highlights that JUST WRITING DOWN what's happening can be a giant leap forward in terms of getting people to agree on what the process actually IS. If you don't write it down, everyone may go on basing decisions on an incorrect understanding of the system.

A related story:

"As I was writing the documentation on our market data system, multiple people told me 'You don't need to do that, it's not that complicated'. Then they read the final document and said 'Oh, I guess it is pretty complicated' "

[Waterluvian]

What drives me nuts is how many people can’t separate those two tasks/projects.

We’re going to write down what Step 7 currently is/does. No, now is not the time to start discussing what it ought to do. Please let us just get through sorting out what Step 7 currently is. Yes, some people do it differently. That’s why we hit a snag. Let’s just pick one of those wrong ways, document it, and do it all wrong together. We’ll fix it as a separate step. Now isn’t the time to fix it, as much as it feels like a convenient time to.

[chanux]

What drives me nuts is how many people don't read!

With that out of the way, the original article and this comment thread really makes me feel good by giving a sense of being right.

> Let’s just pick one of those wrong ways, document it, and do it all wrong together.

This reminds me of my colleague who established the importance of consistency very early.

"If you need to be wrong to be consistent, be consistently wrong".

They say this sarcastically but.. if you are the only sane one among a group of insane, now you are the insane one.

[Telaneo]

If nothing else, if things are consistently wrong, they can be consistently fixed.

[theshrike79]

This is also what's preventing the EU from stopping messing with clocks twice a year.

1) everyone agrees that it's stupid to move the clocks, we have electric lights now

2) NOBODY agrees which timezone everyone should be when we stop messing with the time.

Because solving 1&2 at the same time is about impossible, nothing will happen. What they should do is agree on 1. Write it into irrevocable law. THEN start arguing about 2.

[gishh]

Yeesh. I’ve never worked with a smart group of people who came to that conclusion. That sounds toxic. :(

[alwa]

Which way sounds toxic—wanting to get it right now that they’ve become aware it’s a problem? Or getting something down now, as close as possible to what happened yesterday and the day before, to unblock the larger process—then refining it after the fires are out?

Seems like horses for courses to me: I can imagine my very happy healthy teams needing to operate in either mode, depending on the specific problem. I also can imagine us needing the person closest to the problem to tell us which direction applies.

(To your point though, I also can imagine that any type of pressures like these would really bring out the dysfunction in “toxic” teams.)

[gishh]

> Or getting something down now, as close as possible to what happened yesterday and the day before, to unblock the larger process—then refining it after the fires are out?

In my experience, the refining never happens.

[danaris]

But at least, in that scenario, the process is unblocked.

The other way, you've blocked the process until every subcommittee of the committee assigned to fix the process has delivered their Final Report Draft 8 FINAL (1) (13) (1).docx. And that could be preventing an entire department from working at all.

[machomaster]

Sometimes blocking the process is the best way to do. Blocking gives leverage and allows to fix long-standing inbalances.

Imagine that you have been slaving for low salary with abusive boss, who constantly promises but never delivers. If shit hit the fan and you are desperately needed, this is the perfect time to talk and solidify improvements. Game does not run on gratitude.

The same rule unfortunately also applies to relationships.

[gishh]

I think you identified the problem.

> subcommittee of the committee assigned to fix the process

That bit, is the problem.

[hashstring]

What do you mean exactly?

[Telaneo]

I've been in discussions about Step 7, and my god, the experience was soul crushing. Even more soul crushing was that the result of that discussion was to not document Step 7, because doing that might enforce the idea of what it should be for and why it should be done.

Writing stuff down is great since it provides a baseline to agree upon, and later additions to the team will take it as given and not start to discuss minutiae and bog down discussions into nothingness. And if some point really is worth discussing, it shouldn't be hard to find support to change it. I've heard some wild misunderstandings of how things were based on how they were being done, and now I never want to do anything of any significant size without there being a clear and obvious process to it.

[alexpotato]

> the result of that discussion was to not document Step 7, because doing that might enforce the idea of what it should be for and why it should be done.

In Charlie Beckwith's book about Delta Force [0] there is a line where he says (paraphrasing):

"The SAS never wanted to write down what their role was and what tasks they were trained for. Why? Because they didn't want to get pigeon holed into a role. ... They also never wrote down their SOPs b/c the argument was that 'if you can't keep it in your head, you shouldn't be in the Regiment'. At Delta, we were going to write down our mission AND write down our SOPs."

0 - https://amzn.to/4ahIAJV

[Telaneo]

For a force whose goals can change at any moment, this seems pretty reasonable. The SAS shouldn't be trained for anything in partucular, but rather for anything and everything. Not to mention that in the SAS you have a commanding offiser who can overrule if needed.

Step 7 in a process which already has defined end-goals though? The fact that there were disagreements in the first place baffled me. The fact that it was impossible to write anything down about it without invoking heaven's wrath made me quit.

[hammock]

Your story and the article’s thesis that AI is for acceleration and automation (not other things like design/intelligence) remind me of one particular CEO’s five step product process:

1) design smart(er) requirements- I.e beat up the ask and rewrite the problem statement correctly. 1B is every requirement has a persons name attached who is traceable/responsible for its inclusion- not a department.

2) delete features you don’t need or which are hedges (if you aren’t adding back 10% of the time, then you aren’t deleting enough)

3) simplify or optimize. This step must come after 1 and 2 so you aren’t wasting effort optimizing the wrong thing

4) accelerate

5) automate

This way is very clear where AI plugs in- and more importantly, WHEN it plugs in.

Also, plenty of times people try to run this process backwards, with poor outcomes.

[BinaryIgor]

Writing is such a powerful and often underrated and underutilized tool; I don't think it's an overstatement to say that it's at par with fire and should be in the top 5 of all-time humanity inventions/discoveries.

[MengerSponge]

Feynman's Algorithm:

Write down the problem. Think very hard. Write down the solution.