4 ms·
If you know the address, it is a matter of figuring out directions. But if you do not know the address, no directions may be discovered. How do you figure out t
by lo_zamoyski 3y ago
If you know the address, it is a matter of figuring out directions. But if you do not know the address, no directions may be discovered. How do you figure out the address?
If you cannot determine what needs doing, you cannot determine how to do it. How do you determine the what?
The answer is in the problem statement, but first you need the problem statement. How do you get to the problem statement?
It is easier to follow orders than it is to determine what the orders ought to be. How does one determine the orders?
How shall we live?
A solution is a response to a question asked within a context of presuppositions and facts. But this is not necessarily a one-directional process in practice. In practice, we do not know the context entirely and in the needed resolution. Thus, we often learn from our attempts at a solution that something in the presuppositions is amiss. And indeed, this is how science functions and how Socratic dialogues proceed. A critical experiment can reveal that something is wrong, but it cannot tell us necessarily what. The needle in the stack of theories, and common or philosophical or merely technical presuppositions, is not necessarily in the theory being tested, though that it where we begin for economical reasons.
You need prudence, the heart of practical reason, to know what to do.
And then you need to actually do it.
- csmeyer 3y agoThis comment should be a post itself!
- AndrewKemendo 3y agoThis x100 I got to a repeatable functional process to do exactly what you described when I started applying the state machine design pattern to organizations - and the accompanying broader Markov Decison Process that allows it to iterate. You need to define two states: 1.Current state 2.Desired next state Once you have your states, then you build a “transition matrix” that is unique to this state transition which will guide the “how.” To be clear “organizational state management” is not some turn-key, set it and forget it mathematical, solution. It’s a simple metaphorical method, But the structure is one that reveals the simplest path to a defined target condition by demanding observability for each step and begs the question of how to draw the map.
- alfonsodev 3y agohow do you navigate picking the right level of specs for "Desired next state" to me that's hard in personal projects for instance you can choose for a variety of topics then have to decide how deep you get into each. I guess I'm asking if you have a heuristic for what's a good enough desired next state.
- AndrewKemendo 3y agoGenerally it's based on whatever the next big economic decision point is So if the desired state is "New feature X generates Y new revenue per month" then we need to define the state map of the system where that would be true. That begs many questions then, which reveal our state variables: "What feature metrics do we bill for, in what increments, and on what frequency?" - Business Model "What scale is required for that transaction frequency?" - Infrastructure planning "What amount of downtime can we afford and still meet y goal" - Observability Requirements "What tools do we add to help us build?" - Development Environments/Practice etc... until everyone is satisfied that you can map the current state of things, through this transition matrix of questions and into the goal state. The other piece is having an accurate map of the current state of all your dependencies - including people, time, money, focus, etc...
- victor106 3y agoInteresting. Any resources to learn more about this?
- nathan_jr 3y agoMy favorite template for defining the two states & transition path is the A3 Plan popularized by Toyota. I have returned to it over and over throughout my career as a simple and effective problem solving tool.
- AndrewKemendo 3y agoI'm not working off of an existing framework, just my own experience and battle scars. I'd certainly take the time to write my state management process out if there's interest though! Would you read it?
- malfist 3y agoI really like your comment. I plan on using it next time product asks me "how long will it take" when we haven't gotten anywhere close to deciding what "it" is. We don't know where we're going, we don't know how we're getting there, I can't possibly tell you how long it'll take to get there.
- crazygringo 3y agoWhat you're describing is a bidirectional iterative process that prioritizes building and testing and feedback. Which is the entire point of agile, even though most people here seem to hate it.
- deleted 3y ago[deleted]
- meheleventyone 3y agoAgreed but you don't need agile and a lot of the hate I think comes from it not actually being a bidirectional iterative process for most people in 'agile' companies.
- Turskarama 3y agoWhenever you talk about "agile" you need to be specific: are you talking about actual methods to achieve real functional agility in your team? or are you talking about consultants selling the idea of scrum which management just turns into a daily hour long meeting? Both are called agile but they're very different. Most people will agree that the first is good and the second is bad.
- mattbrewsbytes 3y agoI like to call it small "a" agile vs. big "A" Agile. The difference being big "A" Agile has companies selling prescriptive solutions, ticketing systems, books, consultants, etc. and then management that hears about a silver bullet and thinks it solves all their woes. Small "a" agile is an iterative process with a tight feedback loop, small testable deliverables and a backlog where prioritized items bubble up resulting in other items getting stale. Stale items are good in the sense that you didn't build, test and deliver something that is of little to no value.
- ElevenLathe 3y ago> It is easier to follow orders than it is to determine what the orders ought to be. How does one determine the orders? This is true when you are given orders of exactly the right specificity, and at no other time. In my experience, most orders are either so vague as to barely be orders while also obscuring all context necessary to determine what the requirements might be ("implement tagging") or so specific that they are a death march and probably won't work anyway ("Here is a UML class diagram. All you have to do is turn it into working C++ code."). In my opinion, any worldview or theory resting on the assumption that the people giving orders have it harder than the people following them is wrong until proven otherwise. It's very plain to anyone with real experience that the reason everybody wants to be a General is /because it's easier than being a Private/.
- chinchilla2020 3y agoThat is why I have always loathed the old-school essay https://en.wikipedia.org/wiki/A_Message_to_Garcia https://en.wikipedia.org/wiki/A_Message_to_Garcia . It describes a situation where a lazy manager simply wants someone to follow directions rather than gather requirements. It was lauded as a work of genius business prose at a company I worked at and fortunately departed.
- beaker52 3y agoThe solution is almost always “fuck around and find out” (FAFO).
- bjornsing 3y ago> It is easier to follow orders than it is to determine what the orders ought to be. Depends on the problem space. For example, any dimwit could have ordered any mathematician to prove Fermat’s last theorem. That doesn’t mean it was easy to actually do it.