Structured Thinking vs. Going With The Flow
adamsmith.cc
adamsmith.cc
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.
Perhaps you give some examples of fields that are competitive analysis fields? Or define "competitive analysis"?
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.
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.
I highly recommend it. It's an old book, but a good one.
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.
Great way to view "data science". Augemented intelligence will usually beat artificial intelligence.
«Meeting people: use go-with-the-flow when possible, i.e. unless you really do need to judge/understand them.»
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!"
structured - If you see dirty points showing your hands resting while thinking.
go with the flow - No dirty points. You usually go to grab a tea or coffee whenever you want to think more deeply.
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.
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.)
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.