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.
> 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/.
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.
how 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.
Generally 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...
My 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.
Worked well for us for restructuring 200 people with that. Basically the tech savy people and the ones doing most of the difficult work sketched the interactions and how the project unofficially worked and we restructured along the "real architecture".
I 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.
I 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.
Agreed 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.
Whenever 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.
> 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.
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.