This has been a topic on my mind for quite some time now ever since I worked in Shanghai in 2016 and witnessed things that quite annoyed me, especially from a software engineer prospective.
So the backdrop is that Chinese people have been encouraged by the country's phenomenal success in economy and are now moving from made in china to created in china — a sound idea, just like socialism or any other idea someone around the corner has. The idea is not the problem, the implementer is.
Ideas are cheap. There is a problem xyz, easy. The challenge is how we are gonna find a solution for this problem, let alone a satisfactory one? Well, no one can really define that. Even when you talk about a working solution, the immediate argument will be what you mean by working? How do you prove it works? This sounds more and more like an attorney's job now, doesn't it? Well, let's leave this philosophical dilemma and rant about why I was annoyed by this innovation wave.
Pls, stop "buzzing"
First, loading buzz words is not innovation. These days just walking into any coffee shop in Shanghai and locate any group of:
- more than 2 people (2 is more likely love birds chatting),
- age band between 20-40
- using laptop instead of smart phone or tablet
- bonus: it's running a PPT
- super bonus: it's running code
Yes, you have just found Latte
entrepreneurs(love this name/ref). Get a cup of coffee and
eavesdrop for a while, the buzz words are bound to flow in full
AI... Whatever the problem is, or even the
solution might be, these are the most common denominators.
I really shouldn't bash these ppl. After all they are thinking, and trying to create a solution. But I was deeply annoyed because — often than not they were using these words as if they were a magic potion! Just drink it and your problem is solved. No! Their conversation barely scratched the surface of these technologies (which I highly suspect it is because they don't understand much of them, let alone first hand experience with them) and rarely you hear a voice cautioning about implication, downside, assumption and risk. But everybody knows that there is free lunch.
Let's say cloud computing. Why cloud? what make a cloud? Yes there is the NIST definition, but that doesn't really mean anything to me if you can't relate it to your own context (the problem we are to solve) and explain (clearly):
- what will a cloud be used for
- how it is going to help
- which layer is going to help, and
- how that decision was made
To the minimum, if you are thinking that building a cloud is more of a HW investment than SW, then you don't know what you are talking about. If you are to rent from services like AWS, then can you tell me what challenge you are most likely to run into (and I can tell you now it is not just money... no, not data security, nor privacy, nor vendor lock in... these are all valid points, but the real bummer, is the learning curve). Yes, people, brain. That will be the hardest asset to come by, and the most valuable in your org. AWS is a wonderful service. It is a Ferrari with a million dials. The magic word cloud computing is not going to just spit out a solution for you. It will help, dramatically, if you know how to tune those dials.
Man! I can't tell you how many times I had to battle some Chinese IT fella in 2015 who wanted to sell his client an Oracle database (the swiss army knife of DB) but failed to come up a single example which feature of the Oracle is needed in his application, and why alternatives are inferior? Come on! if you are too lazy or just not good enough to set up an apple-to-apple evaluation, then all what you are saying about the wonderful things of Oracle, are just a word-of-mouth speculation.
The reason they took the buzz words as solution itself is that they are taking an easy way out — a sounded cure-fore-all instead of acquiring, analyzing and proving domain knowledge:
- How much do you really know the problem? and the context of the problem?
- What's the assumption you are taking to think of this as a problem?
- What method you used to analyze the cause of this problem?
- How do you support your argument? and how sound is your support, both qualitatively and quantitatively?
My problem is that many conversations I have participated all went with roughly 30-min of problem discussion then went right into the grand future of the "what if we get 10% of the 13-billion population using this!?" How exciting! Of course, even selling a million toilet paper is an exciting business, and if you can figure out to sell them by the piece instead of roll, man, you will be a legend for sure. This is not innovation talk; this is a group opium high.
Analyzing something is hard. As a matter of fact, any learning is hard. To understand the problem is the hardest part, if not the only thing it matters in an innovation. Most of us possess domain knowledge of some sort. The quick measure I would suggest is how much time you have spent in that domain. Time doesn't cheat, and practice does make one perfect. So even with a domain expert onboard, the process of knowledge sharing so the software guy can internalize the idea and in turn transform it into his domain expertise, eg. a software model and code, and transfer his thinking back to the team for verification and discussion — this back-and-forth process not only takes time, but is a steep learning on both sides. Most importantly, it takes both sides' willingness to learn in order to work.
So for innovation, it's really a process of learning A LOT OF things which you have little knowledge before, and each must contribute to the pod with his/her sharing. Some of those will be easy to pick up; others, will be frustratingly difficult. If it takes 3 years for a highschool and a 4 years for a college, this mega-million-dollar big problem you are trying to solve can't be easier than those.
Well, now look around, how many team members are excited about learning some coding, or accounting?
Stop IT me
If there is one theme of the buzz word section, it is the dominant relevancy of IT. Yes, software is everywhere; coding is a must have. But then, how many times I saw the poor coder sitting on the side the table, listening in silence, as if the idea flows one way — from business owner to IT implementation.
In China, coders and their managers must have a love-hate relatinoship. They are needed (somehow), but nobody wants to pay him much. Even worse, nobody understands him. He lives without a style and is bad at speech; his jokes are dry; his need is not much; his skill is witch-like, from fixing an iPhone to writing an app, even sometimes a WORD or PPT; and the best of all, there are a dime of dozen of them in job market and by subway exit; whatever their coding language is, they can all do the same thing, and with the same quality, too — poor.
This is really bizzare. Writing software is hard; writing quality one is really really really hard. By common sense you won't look at anyone speaking English to be a novelist, let alone a Shakespeare. But that's exactly the mentality these innovation teams or their investors have. So with such thoughts, on the one hand coders are necessity but certainly not a worthy investment, on the other hand coders lack proper mentorship in work to learn, develop and mature, so their deliveries proved the common bias — "Look, this is scrappy produce/code... I'm totally overpaying you..." sad, sad, sad.
Chinese management and team setup are so used to the hierarchy they grow up with in school, in their previous jobs, and in the society overall, that this is the only format they know. But innovation, as we have argued, is depending on knowledge sharing, cross training, and mutual interest in each other's domain. Hierarchy not only makes information flow in one direction only, but enforces domain silo and ignorance which enpowers the seemingly superior position (mgt? founder? investor?) to legitimize its ignorance — "Hey look, IT guy, I hired you because I don't know IT...".
So how to fix this? Stop using the word "IT"! It's an enormous topic
under this umbrella that each consists of a technology that can be
extremely challenging. If you are an IT guy, do you know
nosql? and deployment? and performance tuning? clustering?
modeling? driver?... and network? server? storage?
virtualization?... So to make things straight, stop IT me. Let IT's voice be part of the
contribution, not just a downstream magic pod that will turn idea into
reality. Let everyone be practical
and specific in term of their domain — yes
I know something about Python and Django web framework; no, I don't
know much about database, networking and storage. Same goes for HR,
for business analyst, for product owner, for investor, and for everone
who takes innovation seriously.
A byproduct of China's economy miracle is an impatience to realize a dream. Even worse, urban legends encourage one to be disruptive, because, just look around, how many new riches found their fortune by disrupting the traditional course with their ignorance and ego alone! The mentality of nothing is impossible is not a slogan, it's a common sense.
But no, innovation is not, and can not be, disruptive. We have argued innovation is rooted in domain knowledge, and that knowledge forms the food chain we see today, which in turn brew the perceived problem. The instinct of redrawing the map to remove that problem is absolutely correct — it's like taking fish out of its tank. It will die. But the new map will have its own quirks, just you haven't seen them yet. So being disruptive in that sense is nothing but replacing the old, visible problems with a promise while repeating "no problem no problem no problem..." to your covered ears.
Innovation is not magic. It can only be a system with feedback loop that can be continuously tuned. Like writing software, you always started with a version 1, and ended up with version 989287429 after that many iterations of trial-and-error. If you ignore (or downplay) the intermediates, viola, your end result looks absolutely innovative! Think about Newton's apple, or Einstein's, or Google, or Amazon, great arts, or any disruptive technology/solution you have in mind, just look closer, read and research, you will find breadcrumbs all over its path. The last push gets all the glory, but the truth is that it's standing on the shoulder of a giant, and the ladder to climb is the spirals of continuous try-measure-tune-repeat.
Yes I'm a tech guy and am on a perpetual learning curve of some new or unfamiliar technologies. With a growing age, I found myself even constantly on a review session of some old technologies — a command line I can't think of anymore after a couple month, a Python syntax that now eludes me and I have to google it — this is not even stackoverflow because SO is used only when I can ask a (smart) question that has passed Python 101. I'm talking about google python built-in function type of basics. Shame. But there are just so many pieces one needs to know in order to build a technology stack. So to me I'm constantly learning, constantly thinking, constantly re-inventing wheels or copying someone else's wheels, and constantly writing something new and fresh that only my brain is producing.
Those last part, if being original and bearing a thought worth talkinb about, is my solute to innovation.
— by Feng Xia