Many years ago I worked at company that sold widgets. These widgets were very complicated and required lots of customisation. The company had developed a pretty large piece of software to help their sales people build complex widget quotes with lots of line items.
This company also had a big off the shelf enterprise accounting system that handled their real accounts.
I had worked at the company for almost 2 years as a software developer when one day I found myself sitting in the accounts department helping Danny with something unrelated. It was then that I learnt what Danny from Accounts actually did.
Every morning Danny would print out the previous days ‘accepted’ quotes from the quoting software resulting in a small pile of paper, one for each customer, with hundreds of line items, for every day. Then, using a ruler and pen to scratch out the lines, he would manually re-enter all of the customer data and their quote information, line item by line item, into the big accounting system. This process took him most of the day, sometimes more if business was good. He occasionally made mistakes that either cost the company lots of money or pissed off the customers.
As a software developer I knew that both systems ran off MSSQL databases. I knew that all the relevent information probably already existed to do the “job” programmatically. I knew that it would probably take a day or two to write a piece of software that did Danny’s job, perfectly every time, in a few milliseconds.
Danny had been doing that job for almost 6 years.
Since that day, whenever I start working with a new company, I try my best to meet everyone and get an idea for what they do and how they do it before I put my head down and start trying to solve any problems. That habit has served me well. In a team of ba/tech/strat/arch people I’m often the only one who knows how the accounts actually work, or how the stock is really procured, or what the weird hippies on the third floor do. (They’re always copywriters.)
But I’m not trying to pretend I have special powers. My point is that you can never assume that other people will have looked at problems like you do, with your knowledge-set. Most of the time other people won’t even see something like that as a “problem”. Danny’s boss never thought to question the process that admittedly pre-dated him. They all have no idea what SQL is and neither should they need to. It’s not their job. It’s yours. (Assuming you’re in a tech field)
What really excites me is how this kind of technology-discovery can be applied to people who traditionally live without the exposure to technology that we do. We now live in world where mobile phones can do things that sometimes even I think are quite magical (think SoundHound and Shazaam). I don’t know what “Danny the capturer of the world” situations exist in an under-resourced high school in a Soweto. I don’t know what efficiencies might just be waiting to be discovered in a clinic in Khayelitsha. I am however convinced that if a large corporate focused solely on profits with a really good, international, management team and a chartered accountant CFO all couldn’t spot that Danny was unintentionally wasting his time (and their money), then I can only imagine what amazing, albeit probably simple, tech-opportunities are waiting to be discovered in the “real” world.
I may not be ready to tackle the townships just yet, and I’m by no means assuming that there aren’t already smart people doing this kind of stuff, but I do look forward to one day being able to spend a few weeks immersed in the daily grind of a township school teacher or a minimum-wage worker, and maybe finding some way to bring a little bit of technological awesomeness and efficiency to their lives.
I know you’re wondering. I did write that software and Danny did need to click a button every morning and watch as the script whizzed by in less than a second, but he didn’t lose his job, instead he was able to move on to tackling more challenging things that actually needed his accounting skills. Everyone’s a winner.