5 ms·

In almost 20 years of working in FinTech at various banks, hedge funds startup etc, a lot of this rings true. e.g. - Critical path/flow diagrams [0] are incre

In almost 20 years of working in FinTech at various banks, hedge funds startup etc, a lot of this rings true. e.g. - Critical path/flow diagrams [0] are incredibly useful for both laying out what has to happen in serial vs what can be parallelized. That being said, I've almost NEVER seen them used and 90% of the time they are used it's b/c I made one - SO many important processes are not documented so people can't even opine about how to fix them. I once documented a process and everyone agreed step 4 was wrong. What was amazing is no one agreed on what step 4 actually was. - Most of the big arguments I've seen about projects are less "what should we do" but more "when do we want it" e.g. one party want's it next week but another one wants to have more features so it will take longer. [1] I've often dealt with this by using the following metaphor: "Oh, so you want to move house every two weeks? If you give me six months I'll build you the world's most amazing Winnebago/RV with a hot tub, satellite TV, queen size bed and A/C. If you want it tomorrow I'm going to give you a wheelbarrow, pillow and an iPad." 0 - https://www.howtomakesenseofanymess.com/chapter3/67/2-flow-diagram/ https://www.howtomakesenseofanymess.com/chapter3/67/2-flow-d... and https://www.howtomakesenseofanymess.com/chapter3/71/6-swim-lane-diagram/ https://www.howtomakesenseofanymess.com/chapter3/71/6-swim-l... 1- https://www.howtomakesenseofanymess.com/chapter3/51/reality-involves-many-players/ https://www.howtomakesenseofanymess.com/chapter3/51/reality-...

miroljub 1y ago
Thanks. This single comment provided more value than a page itself.
roenxi 1y ago
> Critical path/flow diagrams [0] are incredibly useful for both laying out what has to happen in serial vs what can be parallelized. That being said, I've almost NEVER seen them used... Making technically good decisions is one of a distressing number of domains where making any attempt at all will put someone a long way ahead of the game vs most people who wield power. Several advanced techniques that nearly nobody seems to do: "Do we have evidence that this is a good idea?" "What if we assume that we achieve the most likely outcome of this action, based on past experience and checking what happened when other people tried doing it? Is it a good idea?" [0] "Assuming we just keep doing what we're doing, where will we be in 12 months?" [0] Please someone get this one into the mainstream US debate next time they're trying to start a war.
- bombcar 1y ago
  99% of all leadership is making a decision and then asking for data to support that decision unfortunately.
  - balderdash 1y ago
    I’ve literally never seen that happen. It’s always problem, initial hypothesis, request for data (then data is either unavailable or typically supports the hypothesis, occasionally the data doesn't and you go back to the drawing board.
    - morkalork 1y ago
      Have you worked on a data team? I've seen that bs a number of times, it's how I mentally grade different managers and PM/POs. Re the unavailable data: Smart people ask before a big change, get told what devs are missing and need to instrument/record and then leverage those new metrics for the before/after comparison. Not-smart people yolo the changes, ask for the metrics after and go whoops it's too hard or impossible to check.
      - balderdash 1y ago
        I’m sure it does happen but a number of times does not come close to all (99%)
  - bsoles 1y ago
    Like when my company's bosses decided: - (pre-Covid) No working from home, face-to-face time is essential for innovation and collaboration. - (during Covid) We are doing a great job WFH. Our productivity did not decline. - (after Covid) Return to the office. Face-to-face time is essential for innovation and collaboration. And always supported with "data".
    - dataflow 1y ago
      Those are not contradictory. Edit: changed question mark to period to clarify.
datadrivenangel 1y ago
The degree to which people can disagree on what things are is very impressive. It once took me weeks to get a company to go from 12 definitions of user retention to 4...
- hobs 1y ago
  I have had people have vicious arguments what a user even was. I just setup a system where custom definitions are allowed because if you want to argue do it with someone who gives a damn.
KolibriFly 1y ago
Flow diagrams are criminally underused
- amelius 1y ago
  Yeah, but hammers are overused.
Aurornis 1y ago
I’ve seen this a lot, too, but only in specific company cultures. The common problem among all of them was that people in middle upper management thrived in chaos. They didn’t want the important things to be well documented or stable because that took away their opportunities to be the important person who held the secret knowledge to make things work. When something broke they wanted it to remain impenetrable for other teams so they could come in as the heroes. Oddly enough, these same people would be the ones pushing for documentation and trying to stonewall other teams’ work for not being documented enough. It was like they knew the game they were playing but wanted to project an image of being the people against the issue, not the ones causing the problem. Also, forcing other teams to document their work makes it easy for you to heroically come in and save the day.
- vkou 1y ago
  I mean, asking for other people to document their work takes zero effort.
  - doubled112 1y ago
    Asking doesn't always mean it will happen. It also depends on how many times you ask, and which method you're asking. I've had countless conversations about this with examples. Still, tickets remain some variation of "called, did some troubleshooting, fixed it".
  - foobarian 1y ago
    In the couple of instances I experienced this, the problem is that the system is like the proverbial elephant that a bunch of blind people are familiar with through touching the parts they are next to; but the complexity is in the relationships in-between. There needs to be a person who will take charge and learn/document the whole system, except people who work on it are overloaded and too exhausted to take this on. And management doesn't necessarily have the insight or incentive to make this happen. It's an interesting phenomenon.
EFreethought 1y ago
What software can be used to make Critical path/flow diagrams?
- yread 1y ago
  You can embed mermaid uml markup in github and gitlab issues
  - arcanemachiner 1y ago
    On a similar note, you can embed Draw.io markup when exporting Draw.io diagrams, meaning the image contains the metadata required to open, modify, and generate a new image (which itself can also contain the new metadata). Mermaid has its place, but Draw.io is so much more flexible.
hinkley 1y ago
I was merged onto a team because we decided to put more wood behind fewer arrows. So I was the Outsider but with seniority and pull (people loved my project and thought we did great, we just couldn’t sell it.) One of the first big problems I solved was almost by accident. We had a backend and a frontend team and we kept missing deadlines because they would work separately on features and the two wouldn’t mate up so we’d have to do another couple iterations to make everything work and “work” belonged in air quotes because things were hammered to fit. The biggest of the problems encountered here was data dependencies in the inputs resulting in loops in the APIs where you couldn’t get one piece of data without another, and vice versa. So we started drawing data dependency diagrams during the planning meetings as an experiment, instead of diagramming the data structures, and the problem went away basically overnight.
- deleted 1y ago
  [deleted]
chanux 1y ago
> projects are less "what should we do" but more "when do we want it" And this usually ends bad. Yet it keeps repeating because there are no lessons learned (but learnings /s). The powers that be keep calling everything a success until the next reshuffle. Then it all repeats all over again (I'm clearly jaded by my recent experiences).

miroljub 1y ago

Thanks. This single comment provided more value than a page itself.

roenxi 1y ago

> Critical path/flow diagrams [0] are incredibly useful for both laying out what has to happen in serial vs what can be parallelized. That being said, I've almost NEVER seen them used... Making technically good decisions is one of a distressing number of domains where making any attempt at all will put someone a long way ahead of the game vs most people who wield power. Several advanced techniques that nearly nobody seems to do: "Do we have evidence that this is a good idea?" "What if we assume that we achieve the most likely outcome of this action, based on past experience and checking what happened when other people tried doing it? Is it a good idea?" [0] "Assuming we just keep doing what we're doing, where will we be in 12 months?" [0] Please someone get this one into the mainstream US debate next time they're trying to start a war.

bombcar 1y ago
99% of all leadership is making a decision and then asking for data to support that decision unfortunately.
- balderdash 1y ago
  I’ve literally never seen that happen. It’s always problem, initial hypothesis, request for data (then data is either unavailable or typically supports the hypothesis, occasionally the data doesn't and you go back to the drawing board.
  - morkalork 1y ago
    Have you worked on a data team? I've seen that bs a number of times, it's how I mentally grade different managers and PM/POs. Re the unavailable data: Smart people ask before a big change, get told what devs are missing and need to instrument/record and then leverage those new metrics for the before/after comparison. Not-smart people yolo the changes, ask for the metrics after and go whoops it's too hard or impossible to check.
    - balderdash 1y ago
      I’m sure it does happen but a number of times does not come close to all (99%)
- bsoles 1y ago
  Like when my company's bosses decided: - (pre-Covid) No working from home, face-to-face time is essential for innovation and collaboration. - (during Covid) We are doing a great job WFH. Our productivity did not decline. - (after Covid) Return to the office. Face-to-face time is essential for innovation and collaboration. And always supported with "data".
  - dataflow 1y ago
    Those are not contradictory. Edit: changed question mark to period to clarify.

datadrivenangel 1y ago

The degree to which people can disagree on what things are is very impressive. It once took me weeks to get a company to go from 12 definitions of user retention to 4...

hobs 1y ago
I have had people have vicious arguments what a user even was. I just setup a system where custom definitions are allowed because if you want to argue do it with someone who gives a damn.

KolibriFly 1y ago

Flow diagrams are criminally underused

amelius 1y ago
Yeah, but hammers are overused.

Aurornis 1y ago

I’ve seen this a lot, too, but only in specific company cultures. The common problem among all of them was that people in middle upper management thrived in chaos. They didn’t want the important things to be well documented or stable because that took away their opportunities to be the important person who held the secret knowledge to make things work. When something broke they wanted it to remain impenetrable for other teams so they could come in as the heroes. Oddly enough, these same people would be the ones pushing for documentation and trying to stonewall other teams’ work for not being documented enough. It was like they knew the game they were playing but wanted to project an image of being the people against the issue, not the ones causing the problem. Also, forcing other teams to document their work makes it easy for you to heroically come in and save the day.

vkou 1y ago
I mean, asking for other people to document their work takes zero effort.
- doubled112 1y ago
  Asking doesn't always mean it will happen. It also depends on how many times you ask, and which method you're asking. I've had countless conversations about this with examples. Still, tickets remain some variation of "called, did some troubleshooting, fixed it".
- foobarian 1y ago
  In the couple of instances I experienced this, the problem is that the system is like the proverbial elephant that a bunch of blind people are familiar with through touching the parts they are next to; but the complexity is in the relationships in-between. There needs to be a person who will take charge and learn/document the whole system, except people who work on it are overloaded and too exhausted to take this on. And management doesn't necessarily have the insight or incentive to make this happen. It's an interesting phenomenon.

EFreethought 1y ago

What software can be used to make Critical path/flow diagrams?

yread 1y ago
You can embed mermaid uml markup in github and gitlab issues
- arcanemachiner 1y ago
  On a similar note, you can embed Draw.io markup when exporting Draw.io diagrams, meaning the image contains the metadata required to open, modify, and generate a new image (which itself can also contain the new metadata). Mermaid has its place, but Draw.io is so much more flexible.

hinkley 1y ago

I was merged onto a team because we decided to put more wood behind fewer arrows. So I was the Outsider but with seniority and pull (people loved my project and thought we did great, we just couldn’t sell it.) One of the first big problems I solved was almost by accident. We had a backend and a frontend team and we kept missing deadlines because they would work separately on features and the two wouldn’t mate up so we’d have to do another couple iterations to make everything work and “work” belonged in air quotes because things were hammered to fit. The biggest of the problems encountered here was data dependencies in the inputs resulting in loops in the APIs where you couldn’t get one piece of data without another, and vice versa. So we started drawing data dependency diagrams during the planning meetings as an experiment, instead of diagramming the data structures, and the problem went away basically overnight.

deleted 1y ago
[deleted]

chanux 1y ago

> projects are less "what should we do" but more "when do we want it" And this usually ends bad. Yet it keeps repeating because there are no lessons learned (but learnings /s). The powers that be keep calling everything a success until the next reshuffle. Then it all repeats all over again (I'm clearly jaded by my recent experiences).