Some technical problems can’t be solved by software or code alone; they are systemic, and require a solution that takes into account the impact that other moving parts have on it as a whole. Lochner Eksteen, Managing Director at EXAH, uses Systems Theory to ensure developers integrate solutions into the entire system for which they’re building. This approach enables them to hone their problem–solving skills, and to build more robust, more integrated, and therefore more impactful solutions.
A short intro to ‘Systems Theory’
At its core, Systems Theory (ST) acknowledges that any ‘whole’ is made up of many moving parts – all of which impact each other in such a way that a change in one will influence another. As a result, working on and isolating the parts of a system – a ‘system’ here could be an app, a product, or even a company and its teams – risks the other parts of that system being negatively impacted. Lochner uses an analogy to illustrate this concept:
“A bodybuilder who wants to improve one part of his ‘system’ – which, in this case, are his muscles – spends a lot of effort, money and time on that. But he forgets to service his kidneys with water over that period, and he dies 10 years later of kidney failure. Over–focusing on one part of a system is completely detrimental to the other parts of the system. Everything needs attention.”
In other words, when a system is seen only through its individual parts, and not as an interaction of all those parts together, it loses its essential systemic properties – and therefore, fails to function as effectively as it could
An ST approach to development, therefore, means that a developer spends less time actually coding. The majority of the time is spent understanding and unpacking the system at hand, and figuring out how to improve the system as a whole.
In Lochner’s experience, spending less time on actual coding is useful because the challenge often doesn’t lie within the software alone. A lot of of EXAH’s clients are companies wanting greater visibility on a certain thing – cross-functional communications between teams, for example – and just building a technical solution won’t necessarily help contribute to this and solve the overall problem: “Your technology is not the only part that’s under stress; it’s a mixture of people, products, services, customers, infrastructure… all of that needs to fit together in the end somehow.”
In the sections below, Lochner goes into more detail about how EXAH uses ST to develop software more effectively.
How EXAH implements a Systems Theory approach
Lochner says that a developer’s technical mind gives them a unique ability to spot inefficiencies in a system, and have the technical know-how to solve those problems. This means that Lochner puts his developers in front of the clients they work with to understand the problem first-hand, and then own building out the system and finding the places where it breaks:
“Developers have got this specific, unique way of thinking that is more valuable than their ability to code. Regardless of their language, they all have this pedigree for understanding how a system works and what it needs in order to function optimally.”
In Lochner’s team, this process that a developer follows – before starting on any code – is split into two main parts: discovery, and blueprinting. Here’s how they do this.
Step 1: Detailed discovery
When a new client comes in, the first month of engagements are mainly conversations between the developers involved, some of the architects, and the clients. That time is spent getting an idea of what their company looks like from a systems view.
This discovery step is crucial for two things in particular: Making sure that the issue the client wants addressed is in fact that thing that needs fixing, and then making sure the solution they build integrates well with the client’s existing system. “It’s just like starting to build a house without any knowledge of the landscape, any knowledge of sewer pipes, or electricity availability. You can’t just start building; it’s a massive risk.”
In order to nail down a proper scope of the entire system before launching into a project, Lochner says his team uses a set of questions on a checklist. From an ST approach, this allows the developers to know where they can innovate in the system, how different parts connect and where they are connected, and where they need to expect some kind of work before being able to adjust what’s there:
“If there’s some legacy system that we can’t replace, that was built on Delfi, the devs need to know about that so they can prepare for that in their workflow later on”, he explains.
Some of the questions they ask include:
- What is your company organogram?
- What are we going to need to integrate with in the future?
- What are legacy systems that we won’t be able to replace?
These questions also help Lochner’s team address and unpack a client’s uncertainties. From an ST approach, this makes it easier to get a sense of what the actual core issue is – a client might say it’s tracking the pink slips that get handed around, but it might be that they send pink slips in the first place – and therefore work through the system in greater, more valuable detail.
Some things asking these questions help unpack are:
- Value uncertainty: This makes sure that EXAH’s development team, an external dev team, is going to be able to deliver the right kind of value for this client, that they wouldn’t have been able to get from contracting or from their own team.
- Process uncertainty: “Clients don’t understand the process of what development teams need to go through”, Lochner says, speaking from his experience. Often, for clients, it might feel like just getting something built by a dev team. However, by outlining their ST approach, and what that entails, they give clients surface area to ask questions, as well as see opportunities for leveraging the integration of the solution into their entire system.
- Readiness uncertainty: Here, Lochner’s team get clients to ask themselves, “Am I ready? Is my company ready? Do I have enough cash flow? Do we have the infrastructure to support all these automations?” – because, as Lochner explains, the integrated solution may change a client’s workflow. For example, all of a sudden, a client’s production time might decrease by 50% with the new integrated solution, “but can they actually supply the amount of raw material to adopt or even just maintain that new growth?”
Once Lochner’s developers intimately understand the system and where it can be improved, they move into blueprinting the system with all its moving parts.
Step 2: Blueprinting
The blueprinting phase is done on Miro, which Lochner says has been a fantastic tool for them to map out the system in the kind of detail they need. In order to have a strong foundation upon which to build a solution, Lochner’s dev team needs an end-to-end system diagram.
For example, one of the systems EXAH’s developers might need to unpack is a company, where its different teams are the moving parts that need to interact. In this case, mapping it out would require laying out where all the teams are situated in terms of their role in the company, highlighting all the touchpoints and interactions between those teams, and defining what those touchpoints look like – be it emails, in–person meetings, or Slack messages. From there, they cab start ideating technical solutions to improve that system.
“We need to make sure that everything is as well scoped and as well thought out as possible before we take that aircraft off the runway”, Lochner explains. Otherwise, the picture is incomplete and, to his earlier point, a developer won’t be able to spot the opportunities for integrating the final solution.
Although Lochner has different templates for the different kinds of clients, two pieces of information he suggests to include in whatever template you use are:
- Handover points: Wherever some kind of information is transmitted, it’s labelled a handover site during the discovery phase, and gets marked on the system Lochner’s developer maps out in the blueprinting. This is because handover sites are often prime opportunities for system inefficiencies and for building an integrated technical solution that makes it easier, less risky and more visible. In the ‘pink slip’ example from earlier, this would’ve been marked as a handover site with a certain colour sticky on Miro.
- ‘Front and backstage actors’: “Anybody that engages with a customer needs to be in the front stage acting environment”, Lochner says. “And then the backstage actors – that’s everybody in the business who forms part of the service, or delivers the product. They never directly interact with customers, but their customers are, in essence, the front stage actors.” In this way, Lochner’s team not only marks touchpoints, but marks the kinds of people who participate in those touchpoints, which informs the kind of software and technical solution the developer might be able to build later on. If it’s someone who is out doing a lot of deliveries, for example, the solution would be different to what the desk–bound HR manager would need.
And, step 3… start coding!
Having blueprints for the system gives the developers enough foundation to springboard into actual development, where Lochner says any coding – if the solution needs it – is now executed.
For more information on ST, EXAH’s video on the paradigm explains in some detail what it is and how they use it. They also have a webinar you can watch, which unpacks it a little more.
