Having previously worked for a global tier-1 business/IT consulting firm, one of the practices I have taken pride in is the prevalence of “best practice” frameworks and methodologies for solving common problems. Doing enterprise transformation? Fine, let’s apply our architecture framework. In need of a different technology strategy? We have a nice digital strategy framework for that. Implementing shared services? No problem, we already have an end-to-end methodology for consolidating shared applications. Superior methodology and framework sit at the core of selling and delivering results. Through this consulting lens we solve problems by looking at prior experience in the tool box, tailoring the approach for framework slightly, and then bending it appropriately around the problem until the conclusions or recommendations stand clear. If it worked back then, then it should certainly apply now as well.
Whilst this experiential approach to consulting has its clear merits, problems arise when consultants start applying it in reverse — bending the problem around the framework. Once a hammer has worked well once, everything suddenly looks like a nail. Unfortunately, I have seen that happen one time too many.
After the transition to a global tier-1 strategy firm, I have been introduced to a quite different way of structuring consulting work. Instead of immediately grabbing out for “best practice” and “global IP”, we spend much more time thinking about and framing the business problem up front, building out and validating the underlying hypotheses for solving it, and establishing the core engagement principles. Even though prior experience is extremely valuable in understanding the problem, establishing engagement principles-first is critical to laying out the strategic context, framing the uniqueness of the challenge, and drawing out particular insights. Whilst it requires more work up front before you start approaching a solution, this means that the resulting product is often much more succinct, lean, and insightful. Results are not dictated by framework-constrained preconceptions of the world. The problem is unique and framework-free. It needs to stand alone for that long – not because it is asking for a solution (i.e. the framework) – but because it caused a headache to someone (the business sponsor). It is also the primary reason for you being hired by the sponsors so it deserves attention.
This is not to say that frameworks, methodologies, and best practices aren’t useful. They are extremely valuable because they provide a pattern for structuring the problem and churning out an answer. The pitfalls appear when we blindly press the framework button every time a problem appears, without thinking about its uniqueness or strategic context first. I would go as far as saying that aspirational or premature application of frameworks, whilst they are put in the world to frame the strategy context in a structured, rigorous manner, actually constrains or negatively affects our ability to comprehend the problem and derive good insights. Frameworks are applied later once the consulting thinking has added structure, rigour, and insights to the problem.
In this post I reflect on the underlying structure and mechanics of these two approaches by investigating the thought process (how we make judgment calls) and the knowledge we produce. Judgment relates to the – be they implicit and explicit – underlying legal framework and morale underpinning our thinking. Therefore it is relevant to investigate how principles/framework-first thinking applies to legal systems and law. Similarly, knowledge production relates to the different perceptions and assumptions we make about knowledge in the context of a consulting engagement. Therefore the second section investigates principles/framework-first in the context of knowledge and the philosophy of the mind. The final section summarises the findings and reiterates why this is so important.
Principles-first and legal systems
Without being an expert in law, allow me to draw an interesting parallel: at a very high level of abstraction, law distinguishes between common and civil law systems. Common law has its roots in the Anglo-Saxon legal tradition in which law is determined primarily on the basis of preceding court decisions. Law is determined over time by judges and it binds future decisions, based on the “principle that it is unfair to treat similar facts differently on different occasions” (source: Wikipedia: Common Law). Examples of predominantly common law systems include UK, Canada, US, and Australia (with a large number of exceptions, of course).
Common law can be largely compared to framework-first consulting. It stipulates that judgments and decisions are made on the basis of prior experience (former court decisions). Previous decisions the groundwork of future decisions. Prior experience takes precedence over everything else in the same way that the “solution framework” takes precedence over context-specific principles or hypotheses.
Civil law systems, on the other hand, finds its roots in the Roman and continental-European legal tradition. The fundamental idea is that a core set of general principles serve as the primary source of law. Whilst prior court decisions and will affect court decisions, the principles and rules of the law take precedence. Unlike common law, civil law treats similar facts differently by assuming that each case is unique and is best resolved by an underpinning set of principles (the law) for informing decisions.
Civil law is principles-first. It is shaped by a general set of generic judgments – the law and constitution – which establish the undisputed terms of reference for every single judgment call. Each unique situation – the consulting engagement – is assumed to require unique treatment in accordance with the underlying principles in order for the court to make a fit-for-purpose decision. Similarly, principles-first consulting forms a set of design principles (the law or constitution) and hypotheses (the interpretation of these principles) for each engagement and applies them systematically in order to derive insights.
Depending on your approach, framework- or principles-first, this will influence your judgment calls. Framework-first judgment calls are rooted in what you and others have done before over time – what has worked and didn’t work. Principles-first judgment reinspects the core principles at every stage of key decisions and applies them rigorously. The outcomes are, needless to say, very different. For example:
Client A has a profitability issue and has engaged you to assess what can be done to decrease costs.
- Framework-first: You engage with the client using an IT-centric application rationalisation framework and assess all applications and systems in terms of cost, function, and strategic value (that’s what the framework more or less stipulates). You come up with a five-year plan to consolidate them and deliver $Xm of savings.
- Principles-first: You engage with the client and build up a set of hypotheses for why profitability is declining. You engage with senior stakeholders to validate and confirm your hypotheses and define a set of principles for further work. The principles dictate that both process and system drive IT costs. The rest of the engagement splits into two work streams – business process and systems review – which uncover process change and system related cost savings respectively. Based on the principles and process changes, you design a future operating model. You come up with a five-year plan to transform business processes and integrate systems in accordance with the target operating model.
Principles-first and philosophy of the mind
Philosophy of the mind provides a similar good frame of reference for understanding how principles-first thinking works. Aristotelian philosophy – that is, the philosophical tradition developed by Aristotle in the Nicomachean Ethics – divides human knowledge into three different categories:
- Episteme, which is scientific knowledge developed through justified true belief or scientific observations;
- Phronesis, which is practical wisdom gained through personal experience and application of ethics; and
- Techne, which is the practical, context-dependent knowledge applied through craftsmanship and art.
Phronetic knowledge is often associated with moral judgment, particularly in law and legal practice (esp. common law as discussed above). Episteme, on the other hand, relates to the universally applicable knowledge acquired in scientific research, especially within science and mathematics. The fundamental prerogative of phronesis is that the ability to comprehend the particular is through past personal wisdom acquired over time. Wisdom allows one to make more informed moral and ethical judgments, which then, over time, is codified into a written law. The act of applying industry-standard frameworks (the past, practical wisdom of consulting firms) in problem solving is therefore an assumption of phronetic knowledge. It assumes that a group of individuals,which have solved similar problems before using a similar methodology or approach, can easily and successfully solve the same types of problems in a different context. Personal calls and “gut feels” are substantially important here.
On the contrary, principles-first thinking starts from the pure indisputable facts (observations, if you will) and builds out specific models and theories of the firm’s context and challenges from that. The knowledge and thought process applied in principles-first consulting is generally epistemic in nature – however, with the fundamental difference that the “subject of observation” (i.e. the engagement context) is not scientific in the same way that lab mice or red dwarfs can be observed and reasoned about. A consulting engagement will always be immersed in a “polyglot scientific” context in which different types of knowledge and approaches – psychology, sociology, technical skills, finance – apply at the same time to the same types of problem but with emphasis on different aspects of reality. That said, epistemic approach to going principles-first ensures that the client context is always approached with a scientific purity, which goes back to basis by assuming that every problem is unique and that it requires a bespoke model, theory, or methodology to truly reason about it.
Summary and: so what?
The above discussion is largely an introverted reflection on the type of work I do every day. Pragmatists would be inclined to think that it doesn’t matter what approach is applied as long as the problem is solved and the client is happy. In the busy life of a consultant there is generally very little time to have second order philosophical reflections outside of the problem itself (second order in the sense that one reflects about the process of reflecting about a problem). As long as frameworks are applied in a sensible manner and the insights are clear, there is no need to think further, right?
Having an informed view on the characteristics of the problems we face and solutions we find is important to being a good consultant, particularly in terms of understanding the mechanics of the underlying knowledge production. Taking a framework-first perspective – say TOGAF at the early stage of an enterprise architecture transformation – provides you with a hammer and morphs reality into nails. It heavily influences the judgments (the legal framework or regulatory framework underpinning your thinking) and calls you will make in solving problems. And, finally, it shapes the way that knowledge is documented and presented to the client (phronesis – “I recommend this because I have seen it before with a different client” — vs. episteme: “I recommend this on the basis of observation A, B and C, which has yet to be disputed by anyone in your firm”). That’s the so-what.
The final pitfall I would like to emphasise is to know when to apply different modes of thinking. If you are reviewing a business case, transforming an organisation, or writing a business strategy from scratch, principles-first is definitely the right approach as it hones in on the uniqueness of the problem. If you are focused on solution delivery and implementation, chances are that existing engineering frameworks are fit-for-purpose.