In my school days it was impossible to score 100 marks in a language class. When I asked my language teachers, they mentioned that there is no definition of perfect language skills at any level, so scoring a 100 in a language test is a disgrace to the language. All the other non language ones had a defined way of scoring 100, if you memorise facts and formulas, then it is easy to score and keep moving up levels. The thoughts ingrain to you that if you follow the plan, keep memorising and apply the facts then you will accomplish a lot.

Photo by Olya Kobruseva on

Unfortunately the world we live is not always filled with templates, more and more problems that could be done with simple cause and effects can be replaced with automations and what is left for humans to solve are wicked problems. Now what is a wicked problem? Instead of going to a textbook answer, let us observe something in an urban neighbourhood.

A neighbourhood’s green grocer is always crowded as the population of the neighbourhood is more than what that store can conveniently service. The store was designed for a people of 700 but the population is 1100. A businessperson sees this as an opportunity to open a new store and draw the excess crowd, but because of the costs of running a store it will take at least 800 people in the neighbourhood to profitably run. When the new store is opened, both the stores will plunge into loss and eventually one of them will shut the shop. Another businessperson will observe the same and repeat the cycle but the problem is never solved. You will see this in every neighbourhood, new grocers, saloons, pharmacies and dentists keep opening and closing over the course of the years and see only a few established shops.

Our system is designed to teach us formulas and templates as an approach to any problem, this is especially on the higher side for premier institutes where people right from a young age are primed to think that way. Learn a formula, apply and observe, change the formula, apply and observe which will just create cycles of boom and bust.

If highly educated professionals specialising in a field cannot easily solve wicked problems then who can solve wicked problems very well? They are solved well only by people who are generalists or polymaths. Problems will boil down to intricate webbing of macro patterns and micro patterns which can be observed in one discipline and implemented in another. It is solved through coming up with a hypothesis (need not even be scientific, gut feel is also hypothesis), try a small solution, expand the solution if it works else ditch the hypothesis and go on with another one. The key is to observe cause and effect across different areas even if they are unrelated and learn from them. Like a botanist playing a violin in free time and figuring out that some plants respond to classical music and grow well, the botanist would have never figured out if there was an alternative passion.

Software development overall is a wicked problem, coding as such is not but building software is a complex dance between people, process and engineering.

Concentrating and learning only technological bits will keep us prepared only to solve templated problems like coding. If we need to scale up and solve business problems through building software then being a polymath will take us a long way ahead.

COBOL was taught to me as a programming language that can supposedly be used directly by business than business telling programmers and programmers writing the code. For people who have never tried COBOL, you write programs called “Essays” with “Paragraphs” and with a lot of capital letters and leaving whitespace margins on the left. The software industry always has this fascination towards no code technology, it wants the business to be able to create software that is not lost in the translation. Which clearly proves the point that building software is not a technology problem but a communication problem in using technology.

Photo by Markus Spiske on

The closest any one getting to success with a no code tool is none other than the infamous excel sheet. Why did it succeed? It succeeded because the data, formula and output were close to each other with a very small learning horizon. Business people who started using it turned it into a personal software that does a lot of things for them but is not useful to put to use even in simple production scales or customise it for others. I have been given excel sheets during requirements phase and asked to transform that into a software that can be used and extended as well. So though it worked, it could not scale to be a full fledged software.

Rather than concentrating on no code solutions as a means to cut down programmer involvement, it should be seen as a powerful tool to enhance communication with programmers on what business is looking for.

Quick prototypes could be made both by businesses and programmers using no code/low code solutions that can shorten the learning horizon. Learn quickly from prototypes and then take it production grade at required scale when you learn from it. Isn’t this what agile manifesto is saying for last 20 years. Produce working software through emphasis on individuals and interactions, respond to change and have business collaborate well with programmers.

One of the elders in my family told me that I will become good at maths if I eat lady’s finger because that is the favourite food of the great mathematician Ramanujan. I believed that firmly and never missed a serving of that whenever it was cooked. I would often practice maths after eating a serving. It went on for a while during the childhood before reality struck me.

We will often see organisations wanting to bring in a change will readily adopt an organisation model from another company. Companies like NASA, Toyota, IBM have inspired management/organisation styles to be replicated like theirs. Adopting something that has been available in the public domain is not going to be of any use. Isn’t it like saying I follow the same things as an oscar winning director and I will win an oscar too?

One of the inclinations people now have is towards the Spotify model which was a matrix organisation with fancy names like squads, tribes, guilds etc. Does the same company follow to the dot on what is available in the public domain from early 2010s? Read this writeup about failed squad goals. This gives an idea that the model has not scaled or worked well for the one who proposed it as well.

Photo by Canva Studio on

An engineering culture is not easy to replicate just by copying the structure and names. Even if it worked for a set of people when implemented, it won’t work well for a long time or when the org grows up. Talent is not a static asset like machine capability that can be made to work in a structure. Government owned enterprises in India were infamous for their quality of work but ISRO which is government owned and has the same bureaucratic organisation, it has exceptional performance in the space program. How come it has the same org structure that has failed every where but works here, it is because of the strong engineering culture left behind by founding engineers which continues to thrive till date.

Before rushing to copy structures, free food, video games, stand ups, OKRs (…the list goes on) the best thing would be is to streamline flow of information between business, product and engineering. Eating the favourite food of a great mathematician does not make me a great mathematician.