Structured Thinking vs. Going With The Flow(adamsmith.cc)
adamsmith.cc
Structured Thinking vs. Going With The Flow
http://adamsmith.cc/structured-thinking-versus-go-with-the-flow
23 comments
Could you tell us about what field this was? :-)
It was a competitive analysis field.
I'm really curious about your answer, but I literally don't know what that means, and Google is not helping.
Perhaps you give some examples of fields that are competitive analysis fields? Or define "competitive analysis"?
Perhaps you give some examples of fields that are competitive analysis fields? Or define "competitive analysis"?
Anything where you analyze a field of competitors. For example, competitive supply chain analysis where you study a competitor's supply chain to try and figure out various things about them. Can they lower their prices? Do they have alternative suppliers for xyz component? What happens if that component goes off the market and how does it impact their bom? How is that component shipped? What's the expectations of them keeping up with the state of the art for this product? etc. You can also do a human version and look at who in organizations are doing this and if you have enough information about their social network can sometimes predict behaviors of an organization like what suppliers they're likely to go with.
There's lots of data providers for this kind of thing, and anything from press releases to shipping manifests can be used.
There's a bunch of versions of this field and they can be interesting. But they're usually not known outside of the firms that really engage in them. If you're smart about it you can build very structured frameworks and plug in the information and get some insight out of it. Or you can just read lots of press releases and go with your gut like a glorified hedge fund manager.
On the tech side you find lots of opportunity to model things and use NLP tools, mapping tools, that sort of thing.
There's lots of data providers for this kind of thing, and anything from press releases to shipping manifests can be used.
There's a bunch of versions of this field and they can be interesting. But they're usually not known outside of the firms that really engage in them. If you're smart about it you can build very structured frameworks and plug in the information and get some insight out of it. Or you can just read lots of press releases and go with your gut like a glorified hedge fund manager.
On the tech side you find lots of opportunity to model things and use NLP tools, mapping tools, that sort of thing.
Thanks for your explanation, that's fascinating.
In my experience most people are bad at both, it's just that they think they are one or the other.
Also I would suggest another approach at becoming better: Instead of mastering both styles (which is impossible for most people) it might be better to focus on one style and look for ways to drag the problems that are better solved with the other style back to solutions you already can apply. Stupid example I created just now: Instead of trying to go more with the flow when meeting friends a planner could spent more time before meeting friends to plan and prepare different options. The solution is still not as optimal as for a go-flow-guy, but it is possible to get around it without your friends realizing. On the other hand a go-flow-guy that is writing a master thesis might be better to plan for a very small topic and go for more iterations with the professor to get to a decent paper in the end. In both example I probably fail to show that the guy is actually applying his own style to a problem that is not meant for this style, just that he is more creative and willing to put in more energy to get to the same end result then the person with the other talent.
If you look closely at medium level chess players and kungfu arts then you see that they are also doing something like this. They learn a small set of skills that all focus on very few basic concepts and try to solve other problems by moving the situation back to their comfort zone or putting in more effort.
Also I would suggest another approach at becoming better: Instead of mastering both styles (which is impossible for most people) it might be better to focus on one style and look for ways to drag the problems that are better solved with the other style back to solutions you already can apply. Stupid example I created just now: Instead of trying to go more with the flow when meeting friends a planner could spent more time before meeting friends to plan and prepare different options. The solution is still not as optimal as for a go-flow-guy, but it is possible to get around it without your friends realizing. On the other hand a go-flow-guy that is writing a master thesis might be better to plan for a very small topic and go for more iterations with the professor to get to a decent paper in the end. In both example I probably fail to show that the guy is actually applying his own style to a problem that is not meant for this style, just that he is more creative and willing to put in more energy to get to the same end result then the person with the other talent.
If you look closely at medium level chess players and kungfu arts then you see that they are also doing something like this. They learn a small set of skills that all focus on very few basic concepts and try to solve other problems by moving the situation back to their comfort zone or putting in more effort.
having been adam's co-founder (xobni) and having lived with him for many years - this article describes one of the things I most like & respect about adam. He is incredibly structured in his thinking about everything in life. I brought much more of the go with the flow skills, but highly respect & learned much from his structured approach. His Wiki of Structures for various fields of thinking is linked at the bottom and a must browse http://wikilogic.org/index.php/Home_Page
I think the Six Hats Method of meeting organization could be applied to thinking which allows for some free form and some structured thinking.
I highly recommend it. It's an old book, but a good one.
I highly recommend it. It's an old book, but a good one.
> Very few people are really skilled at both. But as I mentioned in the introduction, you can be one of them if you practice with new experiences, and reflect on when you over- vs under-think through decisions.
So he suggests you should use structured thinking to be good at "going with the flow". With that implying that someone that is good at going with the flow to start won't be able to be good on both.
I don't think this is true, but only his own mental model playing games with his writings. But otherwise, very interesting thoughts.
So he suggests you should use structured thinking to be good at "going with the flow". With that implying that someone that is good at going with the flow to start won't be able to be good on both.
I don't think this is true, but only his own mental model playing games with his writings. But otherwise, very interesting thoughts.
I can't help but be a structured thinker and I have to exert effort to go with the flow. To be honest I probably rarely, if ever, actually go with the flow. If you're strategically thinking that you are going to "go with the flow" then you are actually still using structured thinking. A bit of a catch 22 there.
Adam has put into words the ideas that have been floating around in my head for awhile, and does so in a very interesting way. Cataloging mental models. Cool. Very loosely reminds me of Jung's personality archetypes.
"Machine learning: Explore vs exploit"
-from his wiki
Great way to view "data science". Augemented intelligence will usually beat artificial intelligence.
Great way to view "data science". Augemented intelligence will usually beat artificial intelligence.
the fundamental blocking issue might be that we all think that 'flow' is not in our capability, & that it is possible only for a blessed few. I've penned my thoughts on it in a post I wrote sometime here
http://priyankasriraghavan.blogspot.in/2013/07/flow-let-it-b...
I personally find the following lovely:
«Meeting people: use go-with-the-flow when possible, i.e. unless you really do need to judge/understand them.»
«Meeting people: use go-with-the-flow when possible, i.e. unless you really do need to judge/understand them.»
I was just talking with my roommate about this last night. I think the most important realization is that it is impossible to only use Structured Thinking to make your decisions and that I was wrong to think I ever was. The way I see it, structured thinking allows you to outline all of the pros and cons of the various options in front of you (which then drives creatively coming up with other possible solutions) but that those pros and cons are often not directly relatable, so your decision as to which pros and which cons you will ultimately fulfill is impossible to make perfectly "logically" and instead is made somewhat intuitively. This is "going with your gut" and is a required part of every decision we make.
Somewhat more concretely: Let's say I'm trying to solve a specific problem for my product. I want to add a new, already designed, feature to my app. There are many many different ways this feature can be implemented. Thinking in a structured way helps us enumerate the various different properties of these options. It requires logical/structured thinking to work through "if I implement API expansion only for has_one associations I can do this in the framework of the rails serializers I am already using" and "if I choose to accommodate has_many associations as well I will need to rewrite the code that now uses serializers. If I rewrite that code, I know that it will require more testing and will probably introduce bugs" So here (obviously incompletely) logic has helped me think about all the consequences of the various different options, but there is no way to mathematically relate "increased code complexity" vs. "solves the problem more completely" vs. "principle of least surprise" vs. "principle of immediate feedback" vs. "performance" vs. "code readability" vs. etc. The phrase is, "apples and oranges"
So now that I can make many logical arguments in favor and against a number of different paths forward, a decision must still be made. And it's hard for me to see how that decision is "logical" in any meaningful way. We obviously have heuristics for saying that "in general, something that impacts the user negatively is more important than the code being ugly" but these hierarchies are always fuzzy and they shift depending on the situation. Ultimately, when you choose which path to take, you are choosing which pros and which cons you believe to be actually most important in this moment.
So, logic is an important muscle to work because being better at it gives you access to more complete information about what all the possible consequences of all the possible actions are. But then, going with the flow is also important to practice, and getting better at it I think really comes with practice, because the more decisions you make and observe the outcomes of, the better you will get at having a sense of what the true balance of these apples and oranges should be.
Sort of an aside, but i've noticed recently that in many of the discussions I've had at work designing features the arguments rarely become heated because of the following:
Person Alpha: "Well A implies B implies C, C is bad so we should not do A"
Person One: "Actually A does not imply B, therefore your thinking is wrong"
When someone is wrong in a very discrete logical way, it's easy for the discussion to adapt and move forward. However, the more common way for things to get intense:
Person Alpha: "Well A implies B implies C, C is good so we should do A"
Person One: "Well X implies Y implies Z, Z is good so we should do X"
Person Alpha: "Well, C is a more important gain than Z, so we should do A"
Person One: "No, Z is more important than C!"
Somewhat more concretely: Let's say I'm trying to solve a specific problem for my product. I want to add a new, already designed, feature to my app. There are many many different ways this feature can be implemented. Thinking in a structured way helps us enumerate the various different properties of these options. It requires logical/structured thinking to work through "if I implement API expansion only for has_one associations I can do this in the framework of the rails serializers I am already using" and "if I choose to accommodate has_many associations as well I will need to rewrite the code that now uses serializers. If I rewrite that code, I know that it will require more testing and will probably introduce bugs" So here (obviously incompletely) logic has helped me think about all the consequences of the various different options, but there is no way to mathematically relate "increased code complexity" vs. "solves the problem more completely" vs. "principle of least surprise" vs. "principle of immediate feedback" vs. "performance" vs. "code readability" vs. etc. The phrase is, "apples and oranges"
So now that I can make many logical arguments in favor and against a number of different paths forward, a decision must still be made. And it's hard for me to see how that decision is "logical" in any meaningful way. We obviously have heuristics for saying that "in general, something that impacts the user negatively is more important than the code being ugly" but these hierarchies are always fuzzy and they shift depending on the situation. Ultimately, when you choose which path to take, you are choosing which pros and which cons you believe to be actually most important in this moment.
So, logic is an important muscle to work because being better at it gives you access to more complete information about what all the possible consequences of all the possible actions are. But then, going with the flow is also important to practice, and getting better at it I think really comes with practice, because the more decisions you make and observe the outcomes of, the better you will get at having a sense of what the true balance of these apples and oranges should be.
Sort of an aside, but i've noticed recently that in many of the discussions I've had at work designing features the arguments rarely become heated because of the following:
Person Alpha: "Well A implies B implies C, C is bad so we should not do A"
Person One: "Actually A does not imply B, therefore your thinking is wrong"
When someone is wrong in a very discrete logical way, it's easy for the discussion to adapt and move forward. However, the more common way for things to get intense:
Person Alpha: "Well A implies B implies C, C is good so we should do A"
Person One: "Well X implies Y implies Z, Z is good so we should do X"
Person Alpha: "Well, C is a more important gain than Z, so we should do A"
Person One: "No, Z is more important than C!"
Really bad analyse done by a person who haven't even bothered to find about basic psychological typing systems like MBTI or The big five.
Personally it seems that he describes TI (Introverted thinking) and then label "flow" as TE (Extraverted thinking) or SE (Sensing Extraverted).
Point being, their exist more then two ways to reason about making decision and living life. To me the author comes about as extremely self-centred and self-importante since he hasn't even bothered to look at the field of his topic.
He totally forgets to take account of feelers, people who make decisions based on how they will feel or how other people will feel after a decision.
Personally it seems that he describes TI (Introverted thinking) and then label "flow" as TE (Extraverted thinking) or SE (Sensing Extraverted).
Point being, their exist more then two ways to reason about making decision and living life. To me the author comes about as extremely self-centred and self-importante since he hasn't even bothered to look at the field of his topic.
He totally forgets to take account of feelers, people who make decisions based on how they will feel or how other people will feel after a decision.
For MBTI, it seemed like more of tenuous a J/P mapping. Structured being J, "go with the flow" being P. The structured, high-level/multi-level thinking is more of an extroverted judging function (aka, J-like), whereas the more step-by-step, adventurous thinking is more introverted judging (aka, more P-like).
However, I do stress that it is a tenuous connection. Neither list is a good list of J or P, most notably P.
As a side note, I do find it interesting that many attempts to describe personality or thought process often resemble MBTI in some way.
(I'm a huge MBTI fan.)
However, I do stress that it is a tenuous connection. Neither list is a good list of J or P, most notably P.
As a side note, I do find it interesting that many attempts to describe personality or thought process often resemble MBTI in some way.
(I'm a huge MBTI fan.)
Completely disagree because he has provided reasoning based on personal observation of real-life situations.
That makes it amenable to understanding, evaluation, and practical application by himself and by other people, like me.
The same can't be said for very complex models like MBTI or the so-called "big five" which are difficult to understand and require complex scientific methods to study. Such models may be correct and may be useful, but it would be hard to evaluate their correctness and it would take a vast amount of effort to use them.
That makes it amenable to understanding, evaluation, and practical application by himself and by other people, like me.
The same can't be said for very complex models like MBTI or the so-called "big five" which are difficult to understand and require complex scientific methods to study. Such models may be correct and may be useful, but it would be hard to evaluate their correctness and it would take a vast amount of effort to use them.
Jees - what a misery guts. Loosen up. He's sharing his thoughts. He's not your psych prof.
One of the difficulties in structured thinking in a team environment is the burden of selling the benefits of your model to others. For every hour you might spend reasoning about a problem, you had to spend 2-3 hours selling that reasoning to other people: on your team, in the larger organization, and outside of that organization.
More often then not people were receptive to the concept of it, but when the models got too complex they would dismiss it and fall back to simpler, less useful models, or just "go with the flow" and wing it.
It's a shame really, because I often found myself either working alone on a hard problem or with one or two interested acolytes when more manpower would have definitely been useful.