an organization is a system
Published by Rupert Morrison October 19, 2017
The literature in organization design talks about system thinking and that an organization is a system. Examples include:
- Designing organizations is the process of purposefully configuring elements or organization to effectively and efficiently achieve its strategy and deliver intended business, customer and employee outcomes (Mohrman, 2003)
- Is driven by the business strategy and operating context; requires holistic thinking (systems, structures, people, performance measures, processes, culture, skills…); design for the future; not to be undertaken lightly; a fundamental process and not a repair job (paraphrased from Naomi Stanford, 2007)
So if this is true, should you run a mile because it is too complex? And anyway, what does this really mean? And how, pragmatically, can we make sense of this idea in a value adding way rather than just an academic concept?
Unfortunately (or fortunately, depending on your perspective) we humans have limited cognitive ability. Most of us can only really deal with two variables at any one time. So we have to break the parts of the system down, understand the bit, then chunk it up again. The days of Leonardo de Vinci are long gone.
Let’s start with the organizational system. The below is a depiction (model) of the organizational system (all models are a simplification). An organization has a vision. A reason for being and this is translated into goals & objectives (and more broadly into a strategy in how to get there). Those objectives are delivered by employees who fulfil roles. Roles fit within a reporting structure. The number of FTEs required is the right-sizing question, i.e. how many FTEs do we need? As I and many others constantly say, Org Design isn’t about who reports to whom. It is about what the role is required to do. What decisions need to be made? What activities need to be done? To do these things, competencies are required and employees have competencies. So what is the gap? How are customers going to be served and what are the value chains needed to serve those customers?
If you define answers to these questions, then you have designed your organization. If you just draw org charts you haven’t really got much at all. Just boxes… So what?
The model can be made even more complex… (As can all models. All models are wrong, but some are useful). Some examples of how it is often made more complex is by defining: who is responsible for each customer or an element of the customer value chain. The same is true for projects or risk management… but remember that we can “only really deal with 2 variables” at one time anyway.
That is why, in all our literature, that we define the system in the below chalk board diagram.
So how can this be practically useful?
At its most basic, if you want something done, make clear to the person you want to do that “thing” that they are accountable AND it is them, not someone else. Give them that ownership. Equally, be sure that the key things that need doing are defined and that you have the right people (i.e. the right competencies) on it.
If you think this is all too much, then think about the time and effort that go into generating job descriptions. The elements in a classic job spec are those that are being defined by this system thinking.
To date I have not yet found an organization that has good job specs. (If you feel you have great job specs OR you know of an organization that has good ones, please please let me know. I would love to learn about it). This is not through lack of effort. It is because each job spec is a standalone word document that is more often than not generated for a recruiting or job evaluation purpose (justification of pay and grading).
OrgVue has been developed to solve this issue. To provide a place for defining things like roles; listing out employees or defining processes, competencies, customers… and how they “link”. But linking them all together, you have a “graph”. You don’t have to link them all together, but if you do, then by definition you have everyone’s job spec. You have total transparency on who is accountable for what.
Daniel Pink has famously popularized what really motivates employees in knowledge organizations: Purpose; Autonomy; Mastery. By defining the organizational system, you help to codify the broad organizational purpose and how that cascades. Each role in a defined system, should have purpose. By being clear on the accountabilities of each role, you are giving autonomy. Given the right level of autonomy requires trust. Trust means you have faith in the person’s ability to effectively do the role. This means they need to have enough competence to do the role… they need mastery.
It is all connected and it is all do-able. You don’t need to define everything at one. Start with processes in one area… and move out from there. Take the job specs and “see” what that looks like.
And that is my second to last point. You need to be able to “see” this stuff. It isn’t about codifying it in a black box. You need to almost touch it. Print it out. Break it down, experiment with various options and keep it updated (easily).
Which is why we, for the past 4 years, we have been on the journey of developing OrgVue and the Org Design thinking. It is way the product is schema-less because every situation is different. Equally, it is why we are developing standard sets of processes and competencies models… because they are painful to generate and why create it twice? Build on a starter for 10. It is why we are shooting to simplify as much of the process as possible, hence the push to take out the ACI from RACI (A = Accountable, C = Consulted, I = Informed)… these define roles people can take within a process or decision making… It is why we have made the product so visual with an ability to punch out to vector PDFs (and soon, PowerPoint slides).
To define your organizational system requires considered thought. But now, with Orgvue, for the first time it is actually possible. Embrace that revolution!