The 5 Languages of Digital Systems

Introduction

Having consulted for start-ups, through to SMES to Enterprise clients, you can see the shift of ‘organisation’ that’s needed for a business to grow. What you may find interesting is how each stage of growth is reflected in a different systems language. This article gives you a structure to consider the nature of organisation within your organisation, or business - each one being reflected as a form of language that exists at each level.

Let’s begin with a quick look before we dive in deeper...

The 5 levels

1. Systems language = words
2. Systems language = [rules]
3. Systems language = maps
4. Systems language = maps with goals
5. Systems language = thresholds

Level 1 Systems language = Words

Every business will use words to describe the systems that are operating within an organisation. This is intentionally obvious. 

The question really is this: have people organised those systems into anything more than a heap of collected words. The Systems have Processes and Structures and Procedures and Policies and Protocol, and there are Factors and Variables, and Workflows and Sequences, and Templates and Naming Conventions, and Formats, and Webinars and Goals...and so on. And of course, even at the higher orders of organisation all of these will be there. But in their lowest form they create a rather disconnected mess that takes ages to figure out. If you try and grow by explaining to fellow employees what the protocol is for A, or the procedure for B, or how system X is used for Y, but then system X1 is used for Y1, well, you get the picture.

Even if you write everything down, it can still be nigh on impossible to fathom as there is no order, no logic to it.

Which is why you need to shift to a higher level of organisation, and the language associated with it...

Level 2 Systems language = Rules

Level 2 is when you have ‘rules’ associated with all the elements of the system - but it is the rules that rule, so to speak. It is the rule that applies the order, not any one part of the system determining the rules.

Take the example of ‘naming conventions’ i.e. a consistent approach (a rule) that is applied in any circumstance that can connect otherwise different but related, or separate but related, factors. If you apply a rule, then the naming becomes obvious and there becomes a connection between things that were previously disconnected, no matter what the system. In other words, the naming convention creates the order than connects, despite the systems not necessarily being directly connected.

For me, if I am writing email templates I will use this structure:

[CONTEXT: PURPOSE X] 

E.g.

[ONBOARDING: REQUEST HUBSPOT CODE TO BE ADDED TO SITE]

This is a simple rule that can be rolled out in circumstances where there is a connection between ‘things of a similar nature’:

Email template

Marketing workflow

In this case an ‘email’ would be included in a ‘workflow’, and would be written following the same rule, with the addition of the ‘date sensitive information’:

[CONTEXT: PURPOSE X] with additional contextual information Y

E.g.

The email would be called:

[MARKETING: INVITE TO EVENT] January 2020, London (email 1)

The workflow would be called:

[MARKETING: INVITE TO EVENT] 

Then, as you will have guessed, you could have the following as a follow up:

[MARKETING: INVITE TO EVENT] January 2020, London (email 2)

Within the organisation you really need one person, or team, to ‘go in’ and organise using these sort of principles and then look to add the relevant ‘pieces’ into folders, using the same principle:

[MARKETING EMAILS: INVITES TO EVENTS] or 

[MARKETING WORKFLOWS: INVITES TO EVENTS]

(which could include everything pertinent to the dates of the events you have in the future, as well as keeping those in the past for the data on e.g. goal completion)

Think about how you can apply this principle to image naming, to Folders in the Cloud, to ad campaigns etc. 

It takes a bit of work to get it shaped up, but achieving Level 2 is a must to move forward.

Note: the example given is just one example about ‘rules’. ‘Rules’ will be apparent throughout the business system, so don’t get caught up thinking it is only about naming conventions. We’ll move forward, and you’ll see what I mean.

Level 3 Systems language = Process Maps

Level 2 gave the business an order, but it remains in the mind of the individual to connect the pieces together, if and when they find them.

The next systems language shifts up a level and displays connectedness in a visual format.

This type of map above has embedded rules (a Level 2 quality), including the following:

These diagrams all tend to start at the top/left and work their way across and down the page.

This is the rule we created for our own business, having experimented with other ways of displaying the information e.g. instead of the platforms being at the top, we tried the side etc. 

Knowing there are Rules (Level 2) embedded you can also see the language system of ‘Words (Level 1) too - with ‘workflows’, ‘tasks’ etc. - the difference with this Level 3 language structure is how we can now see the various elements working together. There is ‘flow’.

These ‘Process Maps’ create a higher level of order than the previous two levels, and make everyone’s life easier. At a glance you can understand how information and choices lead to the next stage of the process.

The things these maps lack, however, is ‘goals’ - which is where we go next.

Level 4 Systems language = Process Maps, with goals

Once you have a map of the system, you (often, but not always) will want to look at a mechanism to measure the success of that ‘piece of process’. This is where goals come in.

With the addition of a Goal to a process you have a way to determine e.g. for every 100 people who entered that workflow, 10 people achieved the goal = 10% completion rate.

With goals attached not just to workflow but to other areas of the business, including Customer Service processes (mapped out), and Sales Processes (mapped out), you will begin to see how the ‘parts’ contribute to the overall goal completion rate. You can then consider which are the key elements to test, with the intention of optimisation to improve the goal targets.

Tracking the results in a methodological manner, in spreadsheets as well as dashboards, you can track over time the success of the changes you make.

Level 5 Systems language = Thresholds

Once you have established your business system foundations, everything ‘should be working’ - the next level introduces a new concept: Thresholds

Here is a definition for you:

As we are talking about levels of language within systems, the concept of ‘thresholds’ needs to applied to the eventualities without your own context.

Let’s run through a few examples of how to apply it:

If a Deal ‘stalls’ for more than 30 days at a certain Deal Stage, it may have reached a threshold

If the Cost Per Acquisition of a new customer from a specific marketing channel has exceeded a pre-set level it has reached a threshold

If an Email within a marketing campaign has dropped below a given point, it has reached a threshold; or if it has gone ‘above’ a different given level

If a Training course has limited capacity, you will have met threshold when you

Etc

As you can see, the threshold could be ‘tripped’ by something being higher or lower, or even faster or slower than a pre-set figure. 

It could also be less of an ‘actual number’ than a series of activities that trip the switch and lead to a threshold being met. You could have a Prospect visit a series of website pages, and using insight tools you can work out the company to which the activity belongs, and in turn based on the nature of the pages they visit you may decide to reach out to them directly by phone ASAP.
This happened as I was writing this section of the article, and the threshold met was simple: they visited our Pricing Page, as well as a series of other pages on the website - so I called them.

The system of language at this level will be varied, but may well look like this:

Target of £X, exceeded by Y% (e.g. cost of acquisition)

Threshold of # of X ‘met’ (e.g. event bookings)

Threshold of X% exceeded by Y% (e.g. Website Bounce Rates)

Threshold of X is met (e.g. Lead Score)

Threshold of -X if not met for #Y (e.g. Lead Score is not met for ‘a number of leads’) etc

In other words, you’ve added in a +/- to the Goal you had at the previously level, or that you have ‘baked into the system’ i.e. even if it is not a specified Goal, you may decide that a stall of 30 days at a Deal stage needs to be brought to a manager’s attention.

The system then, has become (to a far greater degree than earlier levels) ‘intelligent’. This intelligence is always going to be determined by the potential capabilities of the systems that you’re operating. 

With the right systems in place you can action a series of activities based upon a threshold being met. Some may be actionable using, for instance HubSpot workflows, whilst others may well need you to use a spreadsheet. 

Whichever method you use, note how the operator at this level of system is looking at the Thresholds (level 5) of the Goals (level 4), within mapped out system (level 3), applying ‘rules’ (level 2), across the system framework (level 1). 

Finally…

Once more we’ve ventured into a familiar territory of 5 Levels of Digital Cybernetics, and once more I hope you’ve found a new way to think as an operator of the system. Being at the helm, steering, is ultimately about knowing the thresholds - the subtlety of adjusting course based upon the conditions, whilst still moving toward the overarching goal of the system.