When starting a new business, you have a blank canvas to work from and are thus able to establish solid technological foundations, upon which to build and scale.
When stepping into an established business however, you never know exactly what you're going to inherit, in terms of systems, technologies, people and culture.
For the sake of this article, which is concerned with implementing technological changes within an established business, let's make the following assumptions:
When stepping into an established business however, you never know exactly what you're going to inherit, in terms of systems, technologies, people and culture.
For the sake of this article, which is concerned with implementing technological changes within an established business, let's make the following assumptions:
- You discover 25+ different systems being used across the business, which aren't communicating effectively with each other (if at all)
- These systems contain differing versions of what, in theory, is the same data e.g. a customer's contact details
- Certain systems appear to solve the same problem, yet they are both being used and appear to contain differing and duplicated datasets
- Some custom software has been created and is being used by the business, but because different people have worked on the project, at different times, a number of different programming languages and frameworks have been used
- You're met with a great deal of resistance from existing members of staff, when you start proposing changes, on the basis that, whilst things aren't perfect, it all hangs together .... just about
- The majority of customers are dissatisfied with the quality and timeliness of service they receive
- Executive leadership expects quick results, on account of cash flow pressures
So, based on that happy list of assumptions, we can safely conclude that you will be walking into the dragon's den.
The question of course, is how best to untangle this mess and deliver tangible results, in a reasonable timeframe.
Well, in a slight twist on the theme of Daniel Kahneman's book Thinking, Fast and Slow, I would encourage you to embrace the concept of "Thinking, Big and Small."
What do I mean by this?
Well, I mean that you should start by thinking about the big picture. For example:
- Compile a list of all the systems, which are currently being used by the business and the people who are using them
- Clarify what these people are using these systems for e.g. what problem are they solving?
- Build an intelligence picture, by asking a shed load of questions of the people using these systems, in order to better understand their frustrations and pain-points
- Map out the relationships that exist or should exist between all these various systems. Same deal for the various teams or departments within the business.
- Where different frameworks and / or programming languages are being used, seek to understand the rationale behind their selection and question whether the right choices were made
After conducting all this research, you will start to develop a sense for the big picture of the company. Think whiteboards, sticky notes and spider diagrams. If thinking in detective terms, you could also imagine pieces of string connecting to pins, which are stabbed into relevant documents, images and newspaper clippings, in an effort to crack the case.
Sticking with the theme of "thinking big" for a little while longer, it's now time to stay high-level but to start searching for patterns.
Look beyond the information that sits before you, along with the connections you've identified and start to identify patterns, by considering:
- The connections that exist, but which don't make sense
- The connections that don't currently exist, but seem as though they should
- The places where effort, data and systems have been duplicated
- The systems, technologies or teams, which are conspicuous, either by their presence or their absence
If you've ever used a design tool like Photoshop or Canva, you will be familiar with the concept of layers.
Your first round of big picture thinking produced the base layer. Now that you've complemented that thinking, with a search for patterns, you can add a second layer, which sits on top of the base layer and starts to present an enhanced picture of what's really going on.
Now, step outside of the project for a minute, talk a walk around the block, breathe in the fresh air and grab yourself a fresh cup of coffee. When, and only when you've done this, should you step back into the room, pull up a comfortable chair and deeply study your whiteboard.
This is a critical stage in the process. Throw your phone out the window. Lock the door. Do not rush. Do not jump to conclusions. This is NOT a time for action. It is a time for quiet reflection.
After you've allowed yourself enough time, to quietly study, consider and interpret your research, early-stage ideas will begin to take shape in your mind.
Whilst still in "thinking big" mode, I would encourage you to grab a fresh pack of sticky notes, turn to a fresh whiteboard and start jotting down your big ideas. For example, these could be things like:
- Ditch redundant systems
- Introduce modern accountancy system
- Build central platform, to connect everything together
- Consolidate duplicated systems
- Establish boundaries between different technology frameworks
Having captured all your big ideas, it's finally time to start thinking smaller.
This is the stage where you should start thinking in terms of a minimum viable product (MVP). Whilst this phrase is typically used in the context of a new start up, I would encourage you to adopt this mentality, regardless of the size of company or project you're working on. Breaking big problems down into a subset of smaller problems, which allows you to reason about them effectively, is mission-critical.
I would encourage you to feed your big ideas into a spreadsheet, which has three columns, namely:
- Big idea
- Time (1-3)
- Value (1-3)
Having done this, you should give each item a ranking, which considers how long it will take you to deliver a solution and once delivered, how much value that will add to the organisation. Needless to say, the next step is to organise your list, so that you gain a sense for the items you should tackle first, on the basis of investing minimum time for maximum value.
The key thing here, is that by delivering something of significant value, in short order, you will be able to demonstrate meaningful progress and by doing so, you will secure buy-in from key members of the team and build momentum for your project.
You will also build your credibility and authority, such that when key decisions are being deliberated upon, your opinion will carry more weight. This will aid your efforts to deliver the technological changes that are required, in spite of the inevitable resistance you encounter.
Naturally, as you dig further into the details of how to deliver each individual project along the way, you will need to engage in more "small thinking" e.g. deciding which frameworks and programming languages to adopt, as well as figuring out the best ways to integrate different systems together, by building API bridges etc.
None of this, is intended to suggest that "thinking big" is more important than "thinking small" or vice-versa. The key thing is to understand the importance of doing both, as doing so will greatly increase your chances of success, when it comes orchestrating disparate systems, teams and technologies.