“Give someone a fish and they’ll eat for a day, teach someone to fish and they will eat for the rest of their lives.” Back in the days when I was an application support analyst I had my own version of this: “Give someone a fish and they’ll eat for a day, teach a man to fish and they will ask you questions about fishing for the rest of your life”, I know that many technologists felt the same way back then, when it’s your job to provide fish you don’t have time to help people catch their own.
By now you’ve probably got the analogy, fish is tech, whether it’s solutions, fixes, or workarounds, it’s easier to give than teach… That is until you have more people needing fish than you can catch for. What now? Do you look for more efficient ways of fishing? You can only do that so many times before returns are diminishing. Do you put the people in a prioritised queue knowing full well that the people at the back are never getting their fish? Of course, the only way forward here is to enable the people who need fish, to get their own.
I admit I went a bit far with that analogy, but the idea holds true, the demand for technology solutions far outweighs the capabilities of any IT department. So much so that the only viable solution is to democratise the technology so that users can create their own solutions. That means that our role as technologists changes from people that give solutions to people that enable others to provide their own solutions. Of course, there will always be complicated solutions that require experienced technologists to implement large scale transformational platforms (forgive me for not having a fishing analogy for that one) but if anything, this strengthens the argument that simpler capabilities need to be delivered by the people that require them.
Once you’ve reached this conclusion you need to start looking at the barrier to entry for creating solutions, right now that is the ability to code. Some institutions see the democratisation of Python being the answer to this, but I don’t think that goes far enough. Think of that idea as a non-technologist that isn’t used to just picking up a new programming language. They know what they want the system to do, so now they must learn how to program before they can do it. That’s not very appealing to someone trying to make their day job easier.
This is where low code platforms make so much sense, very few people think in code (although I have met some that do), so pushing people’s ideas through the limited lens of their understanding of code is going to lead to solutions that don’t do what is needed. Low code platforms, especially ones that take care of hosting for you, will also do an awful lot to stop rogue code doing things it shouldn’t. Do you think the platform provider would be happy to let you run an infinite loop or call potentially harmful APIs? Worried about data leakage? Then only allow the low code platform to connect to approved SaaS platforms. It’s guardrails like these that make Digital Enablement viable, and if you are still into the fishing analogy think of it as building safe piers and jetties at the best fishing spots.
No doubt there are some technologists out there worried that all of this Digital Enablement will lead to their expertise being no longer needed. To them I say “We’ll still need people to make the rods, build the jetties, teach fishing and go after the big ones. How do you want to help?”.
