Get the top HN stories in your inbox every day.
alexpotato
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-d... and https://www.howtomakesenseofanymess.com/chapter3/71/6-swim-l...
1- https://www.howtomakesenseofanymess.com/chapter3/51/reality-...
roenxi
> 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.
psunavy03
> [0] Please someone get this one into the mainstream US debate next time they're trying to start a war.
Speaking as someone with 20 years in uniform and as a War College grad (if only by correspondence) . . . the military ironically has this wired more than any other institution in the Federal government. The reason the military gets drawn into so much of US foreign policy is not because of a fetish for blowing things up. It's because it's the only institution where formalized planning is a thing, the only one where feats of large-scale logistics are par for the course, and the only one where "I'm not going there because I might get hurt" isn't a valid excuse.
As an example, one of the best ways for distributing aid after a natural disaster is an amphibious task force, because you can send the same Marines in to distribute aid that you would to take territory. And going into relatively unprepared areas and setting up infrastructure for follow-on forces is basically their bit either way.
The problem comes in because military force is never the complete solution in and of itself outside of something like what's currently happening in Ukraine. And when you involve all the other agencies plus scads of glory-seeking politicians, it's hard to keep things from becoming a shitshow.
SanjayMehta
Military force, as demonstrated by the US and its allies, worked out really well in Korea, Vietnam, Cambodia, Iraq, Libya, Afghanistan (Taliban 2.0 after 20 years), Syria.
Declaring victory and running way is the common theme of US foreign policy.
Ray20
> outside of something like what's currently happening in Ukraine.
Typical slippery slope. "The problem comes in because military force is never the complete solution in and of itself outside of something like <insert any use of army>"
bombcar
99% of all leadership is making a decision and then asking for data to support that decision unfortunately.
bsoles
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".
BurningFrog
This is also - disturbingly - how the human brain operates.
1. Some subconscious process makes a cynical decision about what course of action is most beneficial for you.
2. Another part, known as the "Press Secretary" comes up with a good sounding motivation for why this is the morally right thing to do.
3. You now genuinely believe you're doing the right thing, and can execute your cynical plan, full of righteous zeal!
I'm as autism-brained as anyone, and would probably prefer brutal honesty in all communications, but I also think you have to accept that well functioning human organizations don't operate like that, and if you want to be part of such organizations it's best for everyone to accept how they work.
nothercastle
I’ll settle for making decisions. Most leaders can’t even do that
balderdash
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.
zhengyi13
"If you torture the data long enough, eventually it will confess to anything"
milesvp
"Assuming we just keep doing what we're doing, where will we be in 12 months?"
I find this one interesting, a business youtuber I follow said he finally realized that his teams all got ~5% better every year if he just left them alone and changed nothing. He said he used to have all these ideas he wanted to implement, but that if they didn’t have a lot of potential upside, they weren’t worth the short term drops associated with reimplementing, retraining and the teams having to relearn and explore their new problem space.
lazyasciiart
> 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]
I’ve tried exactly this and it was shocking to me that even when faced with examples of themselves failing to do something, people would just willingly go on the record with this:
Lindsay: Well, did it work for [us last time]? Tobias: No, it never does. I mean, these people somehow delude themselves into thinking it might, but ... But it might work [this time].
undefined
hinkley
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.
undefined
Aurornis
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
I mean, asking for other people to document their work takes zero effort.
foobarian
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.
doubled112
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".
datadrivenangel
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
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.
EFreethought
What software can be used to make Critical path/flow diagrams?
yread
You can embed mermaid uml markup in github and gitlab issues
arcanemachiner
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.
chanux
> 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
Thanks. This single comment provided more value than a page itself.
ivanjermakov
Reminds me of pilots' decision making process:
- Situation: The pilot is required to recognize the current situation and identify the possible dangers. This is the most important step of the decision-making process since detecting the situation accurately gives the critical information to start the process correctly and produce a feasible resolution to the impending situation.
- Options: Generate any possible option regardless of the feasibility of success. It is most important to create as many options as possible since there will be a larger pool of options to choose the most appropriate solution to the situation.
- Choose: From the options generated, the pilot is required to choose a course of action assessing the risks and viability. Act: Act upon the plan while flying in accordance with safety and time availability. The most important step of this process is time, as the pilot is challenged against time to fix the problem before the situation further deteriorates.
- Evaluate: Ask the question, "Has the selected action been successful?" and evaluate your plan to prepare for future occurrences.
https://en.wikipedia.org/wiki/Pilot_decision_making#Decision...
bityard
There are so many good concepts to borrow from in pilot training, it's almost ridiculous. I'm not even a pilot but have studied risk management, crew resource management, decision making, etc. Anecdata of course but I feel it made a pretty big difference in dealing with projects and problems.
xp84
I’ve been increasingly addicted to Mentour Pilot videos in the past month, and I couldn’t agree more with you. Modern (and by this I mean really 1990s+) pilot training, with its decision frameworks and CRM ideas, is a model for how most professionals ought to organize their work and deal with challenges. Of course it’s easy to see why aviation developed such rigorous systems, but we’d do well to steal as many of their ideas as we can. If anyone isn’t already really familiar with those two concepts especially, I bet it would be worth your time to look into them a bit.
EdwardDiego
If you don't already, check out Admiral Cloudberg's write-ups. She started doing research for MentourPilot last year, but has a few years of previous articles that'll wiki-hole you real good.
bonoboTP
Mentour Pilot is quite good, especially their older videos, tho recently they are moving to stronger engagement farming since they sold to private equity (https://www.electrify.video/post/electrify-video-partners-ex...)
tclancy
Atul Gawande made a book out of the idea (well, sort of!), https://atulgawande.com/book/the-checklist-manifesto/. The original article is at https://www.newyorker.com/magazine/2007/12/10/the-checklist
dsrtslnd23
Reminds me https://en.wikipedia.org/wiki/John_Boyd_(military_strategist... and OODA loops
theologic
At the time of the FAA making up this framework, I would venture more than half of commercial pilots had some military aviation background. It is so close to Boyd's model, I would think that a research might find that it was highly inspired if not a direct descendant of Boyd's work.
However, Body was real time combat, and I think the FAA is supposed to be beyond a cockpit crisis, and maybe another framework is Demings PDCA framework, which looks like you could roughly match the pieces.
michaelrpeskin
One trick that I always fall back on is to make a dependency graph. In meetings I used to pull up yuml.com but now I use mermaid. You can just start typing text and arrows and it renders in real time what depends on what. It's great in a live meeting to help focus people on where the problem really is, or in documentation to show why a change here will affect something there.
Both yuml and mermaid don't get you control over layout. I think that's a feature. If the layout engine can make a pretty picture that means your dependencies aren't too complex, but if the graph looks terrible and complicated, that means you're system is also probably terrible and complicated.
loa_in_
To save others confusion, it's not yuml.com but yuml.me, a UML diagramming tool
michaelrpeskin
Sorry, you're right. It's been so long since I used it, I forgot that it wasn't a .com domain.
KolibriFly
Totally agree on the lack of layout control being a hidden strength. When the graph looks like spaghetti, that's not a tool issue - it's a systems issue
firesteelrain
I wish we could use that. I can’t use them because mermaid doesn’t have a way to assure no data is stored on mermaid servers so I can’t use it for anything proprietary or even work related at all. LucidChart has a way to tie into Corporate though
illusive4080
I just use VSCode with a markdown file and the mermaid preview extension. It’s all local.
https://marketplace.visualstudio.com/items?itemName=vstirbu....
firesteelrain
I can’t even get that approved.
w10-1
mermaid layout doesn't scale for me so I keep using yEd/yFiles and their tgf (trivial graph format -- tab-delimited relations) input with orthogonal layout. It's a bit of a hassle in a meeting but updates take about 15 seconds to refresh if you have everything set up. Automating it fully would require an expensive license.
marginalia_nu
I've observed that messes and complexity often but not always tends to just be noisy information streams. If you try to make a decision based on large volumes of low quality data, the world feels incredibly complex and constantly shifting and self-contradictory.
If you manage to improve the signal to noise ratio it feels a lot more manageable and understandable.
Worked with an enterprise architect once who couldn't say anything that didn't start with "in this complex and ever changing information landscape". You built this complex and ever changing information landscape, sir. It consists of your hexagonal architecture, your microservices, your kubernetes cluster.
01HNNWZ0MV43FF
OODA loops are everywhere https://en.m.wikipedia.org/wiki/OODA_loop
Mobius01
Interesting to see it crop up here. I met Ms. Covert when she released the book and have a signed copy around here somewhere. It remains relevant as ever, and has value well beyond UX practices. It’s a short read too, I recommend it.
mvellandi
Abby is awesome and an old friend from NYC ux & information architecture scene in early 2010s. Her book is great, and like others mention, the homepage is just the TOC. Go buy it! Ultimately, the mess is yours to make it helpful for stakeholders.
jennyholzer
Could you post the names of some influential books or articles from the Information Architecture scene?
I've never heard of it, but I'm impressed by OP's website and I'm interested in learning more.
edit: There's a whole list in the website.
edit (pt. 2): How would you compare the Information Architecture scene to the Effective Altruism scene? Are these scenes linked/overlapping in any particular way?
mvellandi
No link. IA only concerned with organizing info for various mediums and its UX to meet org and individual goals
gowld
Can you gently suggest that she consult her information architect community to help her make her website human readable?
balderdash
My experience is that one mess is pretty straightforward, what is debilitating is interconnected messes.
System A is the highest priority fix and we want to incorporate parts of system B into system A (they never should have been in B) but if we move them to system A, the other parts of system B will break (so we need to fix those) and then additionally system C will no longer work so we need to fix that, and on and on…
csours
Designed by History vs. Designed by Intent
---
Working on a legacy codebase last year I kept repeating to myself: They made it work, they didn't make it sensible.
pimlottc
I was a bit confused by this until I realized that this is just a table of contents and the sentences in each chapter are links. They are not obviously styled like hyperlinks.
danparsonson
Oh! Thank you, I was totally lost and thought it was some weird stream of consciousness or something.
Voklen
Ohhh I did think this was some interesting poetry...
Lockranor
I did the same thing. Very Zen...
undefined
hitekker
You can't talk about messes without talking about Garbage. When a mess is inevitable, maybe even on purpose. Landfills, toxic waste dumps; every organization has them, needs them.
I once worked in a department that was a dumping ground for failed projects. A 10 year long mess; it was both constant garbage and an essential scapegoat. A mess that everyone can blame, from the C-suite, to peer organizations, to even the people who worked inside the org.
Wikipedia has a great primer on the topic, which I think is more incisive than the OP's holistic framework https://en.wikipedia.org/wiki/Garbage_can_model
Get the top HN stories in your inbox every day.
All: "Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They're too common to be interesting." - https://news.ycombinator.com/newsguidelines.html.
It's not that these things aren't annoying—it's that they are annoying, and that drives tons of dyspeptic discussion that in the end drowns out anything that's actually interesting. Since that's a bad outcome, we need to refrain from driving the thread there. (I've moved these complaints to a stubthread: https://news.ycombinator.com/item?id=45389100 - if anyone has an urge to reply, it would be fine to do so there)
(p.s. what look like chapter headings in the OP are in fact hyperlinks)