I've navigated five technology system transitions across 30 years. Now I work with revenue-stage SaaS CEOs on the AI transition - privately, as a thinking partner, with no agenda but theirs.
Engineering, product, executive - three disciplines, full depth. Chief architect. VP Product. CPO. CPTO. CEO. Four exits across every stage.
Most advisors see one slice - technical, product, or business. Three disciplines in full depth makes it possible to hold all of them simultaneously, without losing resolution when the conversation moves between them.
The CEOs I work with have read everything worth reading. The gap isn't information — it's that none of it maps onto their specific situation, and they've run out of people who can help make that translation without an agenda.
Next Steps Towards a "Common Language"
With experience, I have come to realize that is not sufficient to gather a diverse group of people to solve problems, no more so than a pile of sticks is sufficient for a fire.
In part, I think there is a “common language” missing that represents the shared patterns, processes, structures, templates, metaphorical structures, relationships, etc. across a variety of disciplines and domains.
As with any language, agents are required to bring the language alive. In the case of a “common language,” I think the effort to practically capture and utilize is too high without the support of tools to assist. Just as spreadsheets such as Excel and tools such as Mathematica augment reasoning with various forms of math, a “common language” will need supporting tools as well.
To create an organization that intends to reason across disciplines, the language and tools must exist. Without them, it’s unlikely that such an organization could emerge.
Specialists and generalists
I think it’s pretty easy to convince ourselves that in many contexts, especially work, we are becoming more specialized, moving away from being generalists. As an evolutionary process, it allows us to better fill more niches. However, with this specialization, the complexity of communicating across contexts is increased. With a decrease in communication, the opportunities for leverage are similarly decreased.
For as long as I remember, I’ve been convinced that the only way to solve the “really big problems” is with multi-disciplinary teams. Like most things, my conception and understanding of the “really big problems” has evolved as I’ve changed. Over time, they’ve included the academic (how to access enough knowledge to be a true generalist, not a specialist), the serious (how to resolve conflict between radically different cultures) to the silly (how can I fly away from home with my own personal space plane).
No doubt influenced by some optimistic science fiction, the way I saw it as a child is, at it’s essence, the way I see it today: that a group of people from different, diverse backgrounds and interests will solve problems no one else can and will do things others say can¿t be done. Sometimes intentionally (and sometimes not) I continue to return time and again to act on that conviction.
As part of that conviction it seemed obvious to me that there must be a discipline which represents the common foundation underlying the many other domains, i.e. a “common language.” However, I¿ve never found a discipline which quite seemed right, i.e. no university program which teaches quite what I’m thinking of. While some disciplines had a piece which I was interested in, certainly some aspects of the humanities & liberal arts speak to this, other pieces were missing and I could never imagine specializing in that discipline - the results seemed too narrow.
Independent of situation, the interest and conviction has remained. Today it manifests in my education and profession, I have ample experience in the specifics, yet a passion for the general that spans the boundaries of many disciplines.
Formal Versus Agile? You've Got It All Wrong!
As I interpret it, the agile versus formal debate is generally treated as an either or question. For instance, in any given software development situation there may be an assessment that it would have worked better if only an agile approach was used or for a project like this, you must use a formal approach. Only rarely does there seem to be an advocate that suggests integrating aspects of both approaches.
Inevitably, this has resulted in religious arguments about which approach is better, and religious arguments are usually from an absolutist’s perspective.
A funny thing happened on the way to resolving this issue; some folks with poor practices attempt to partake of any legitimacy that the agile approach offers by reinterpreting their practices as agile. Their approach is to elevate any poor practice they have as really being agile. Equally confused, other folks have taken genuine successes from the agile approach and reinterpreted them as luck, hacking, or some other variant of happenstance. Their approach is to reduce any agile success to at best the results of wishful thinking.
What do these two different groups of people, the elevationists and the reductionists, have in common? Both of these groups have a perspective that only allows for two levels of software development: lets call them conventional and non-conventional.
- Conventional: formal or heavy approaches, e.g. Rational Unified Process (RUP), CMM, etc.
- Non-Conventional: anything other than conventional.
In addition, this re-interpretation can be shown to be an instance of a concept identified by Ken Wilber and named the ¿pre/trans fallacy¿. While this think piece is about software development processes, the subject area that the pre/trans fallacy originally referred to is much more universal and significant, that of human consciousness (e.g. Ken Wilber Online: Introduction to Volume 1 of The Collected Works). The pre/trans fallacy is part of a larger model called the Integral Model [need citation].