The common "do-what-you-love = your job" — some memos I'd organized in my sleep about a new way to structure work processes, a post-Airin-full (a new Agile-Lean-Waterfall).
For internal-external departmental or cross-team collaboration, process types largely come in waterfall and agile (or lean). Some think of so-called lean/agile as the "latest" approach, while others say waterfall fits large projects and agile/lean fits smaller ones. Yet others argue that for service vendor work, waterfall is suitable to make cost and responsibility clearer, while for startups building and running their own services, agile/lean is suitable to progressively stabilize and expand according to market response.
But is that really so? Having applied each perspective in practice, both left something to be desired. Why?
My personal answer: the issue isn't which result-oriented methodology you choose; it's that the criteria we use to generate and classify methodologies — our very perceptions of classification — are what must be changed. For instance, the way we organize work folders in daily life differs from how Misaeng's Jang Geu-rae organizes his folders — and that perceptual difference may be the biggest, most fundamental cause.
The background to this judgment: the creation of existing methodologies and the scope of perception distinguishing their types and uses are, themselves, manager-centered. Theatrically, it's the omniscient narrator's perspective — better suited to grasping plot and outline than characters' states or emotions. From the practical standpoint, it's little different from mathematical theory, whose variable controls (friction, resistance coefficients, etc.) cannot really be managed in reality.
Thus it isn't easy to compose, define, and apply work methods/methodologies using management, evaluation, or cost criteria. Because variation by each organization's condition and capability is so large, it seems worth reconsidering whether universal methodologies can be treated in this way.
To make this more practical and participant-centered, to apply it to reality rather than theory, we need a small shift in perception.
It seems more practical to define the criteria that divide methodologies or processes not by the types and kinds of work that make up each stage, but internally by the density of participants' work and externally by the density of user involvement.
Above all, if you want to manage and get results in every detail exactly as you wish, just do it yourself. Diligently grow the capacity to do it alone. With that much ambition, you can certainly do it. Have courage.
Otherwise, or if you judge that you don't have the capacity, don't divide labor — find a way to collaborate. The point is, please don't write "division of labor" but read it as "collaboration." And if you're going to collaborate, don't dictate quantities for work you're not doing. Again, we're talking about collaboration, not division of labor. The manager-executor and client-vendor layers need to be perceived separately. Of course, if it's a cottage-industry-sized project, or you have the economies of scale (money) to run whatever — that's a different story.
