by on

When web 2.0 became the norm, the about of misinformation grew a lot. The more the people were able to write anything without getting embarrassed of being proven wrong, the more the misinformation started coming out. Over time I started learning on how to assign weightage to what I read and have a small set of trusted sources, then I was able to navigate misinformation well. The flood of forwards in then email and now whatsapp which often looked true often have failed even reputed news agencies.

An example of such a forward was the ‘O-Yes’ operating system that circulated in the late 90s. Every college internal magazine’s editors fell for this forward and featured it in their magazines. Even now, Google search’s AI overview lists part of the email as the OS features without debunking it is as a myth. I fought really hard to disprove it during my college days and ended up with a lot of wasted effort as it still got published.

This is called Brandolini’s law, the amount of energy that is required to refute misinformation is orders of magnitude larger than the effort needed to create it. There are another class of problems where if you fight misinformation then you are at the risk of losing your membership/status in the community. For a very long time in India, you cannot tender 10 rupee coins as people formed an opinion that they are fake.

Photo by Insaanu Studio on Pexels.com

The more you are engaged in rapidly evolving landscapes, the more you stumble on this problem. With Gen AI, we are even more hit with misinformation that seems very close being treated as real information. The tool is available to the masses, yet there are fewer individuals who can prove/disprove. False experts, an offshoot of advanced beginners are on the rise due to these tools.

Before Gen AI, whenever I used to interact with the executives, I could sense that the tone of conversation is to understand about problems and solutions deeper. Nowadays I observe a marked shift in the tone towards “oh, I know this stuff, tell me something I do not know yet”.

One solution that often works for me, is to ask for the source of the claim or statement. People struggle a lot to admit what they gained without understanding the source. Questioning the source often works in a live setting where you are either in a meeting, 1-on-1 conversations or talk event like round table. In high stakes conversation, I go with ‘I agree’ and say where it may work and then follow up with why it does not work everywhere else. Due to the effort asymmetry, it is necessary to reserve the strength to confront only the ones that are absolutely necessary.

by on

Demoes are always concepts, they are not a showcase of capability instead it is an artistic impression of what is possible in the end state. A frequent repeated pattern in the enterprise software I see is that – someone builds a something eye catching in a short turnaround time, it gets coverage and people are assigned to take it production and then it stalls like how the loading icon appears when you try to watch a hd movie with a poor connection.

Photo by SHVETS production on Pexels.com

I had been an advocate of rapid prototyping & development and XP practices all along my career. It is in my best interest to find increasingly faster and sound ways of developing software. The first problem to solve in software development is never programming, it is to figure out ‘are we building something that people would want it very badly?’ Building something was expensive so people had to be extra careful to understand if they are going down the right path. With advent of more and more easier programming tools, the building part became easier and easier to the point right now that we can do lots of work in an extremely short window.

Photo by Deniz u015eENGu00dcL on Pexels.com

This paved way for ‘Let us build first and check if it works’. This is where several people stumble and I am reminded of the infamous developer quote ‘It works on my machine’. ‘Works’ means different to different people. Productionising an application is far from development completion. It involves architecting, designing, testing, certifying, securing, scaling, monitoring and on and on. The UX has to be top notch, architecture should be easy to scale, design should be able to add more components with less effort, when scaled and distributed it should take advantage of economies of scale and bring more returns.

Another bigger problem I see with the current state of development is that zero to one has become an easy to solve problem but people are stuck at level one and very few have the capability and grit to move beyond the starting point. What has in fact happened is that the starting line has moved from zero to one, the difficulty of getting to the finish line still stays the same. I feel it is momentary that people are getting carried away and impressed by the quick turnaround time.

Only when all the parts of the cycle from start to finish are transformed to a rapid development pace, then demos will be an engineer’s showcase not like an artist’s impression of how the finished product will look like; which is easy to demo and hard to ship

by on

I have observed one common thing across different organisations I have been associated with, how the appraisal process works. Bell curve is the default standard. Over the many years; I have seen this kill very high performing teams by promoting silos, heroisms and also a rat race to avoid the bottom.

One place I remember very well was when I was coaching a hand picked team. This team was assembled by the business unit leader to adopt XP practices to switch from waterfall. This team was phenomenal, picked up concepts and intents of XP very well and showcased to the entire org on what lies ahead with the new ways of working. Then came in the annual performance review. Until that point I have not see the ill effects of a bell curve, it was always give your best and reap the benefits.

Lion and fox chasing impala on dry savanna grassland
A lion and a fox chase an impala across the African savanna at sunset.

This was a curveball that no one expected in the team as they thought they were immune from the old ways of performance management. As per the process, one of them will be labelled as a non or poor performer and penalised. So much for a team of handpicked top performers in the org. In the end, the one who was named as poor performer left the team and the org. It was a lose-win situation, the org and the team lost a good developer but the developer got a bigger and better role due to the upskilling.

When I asked an executive about this, the answer I got was that “It works for me and everyone around. Why fix something that is not broken?” That was an answer that stumped me on how normalised this has become. I know I can’t fix their process overnight but planted a thought on them by reversing the decision process, why are they limiting the number of people who can perform better than that is expected of a role. Aren’t they signing up for less?

The executive accepted but said that too little can be done about at large corporates. Many of them are too big to fail and have a good market share that it is hard for them to get disrupted. I did not give up though, I was able to persuade some of the smaller companies that I was involved to look away from this bad system of finding a prey and become a prey. Bell curve or forced ranking is quite detrimental to collectively up the game for an organisation.