A doctor whom I met, was upset about dealing with a lot of people coming to clinic equipped with wikipedia and LLM generated knowledge. Years of education and practice puts a doctor in the zone of unconscious competence, but for an expert beginner with no formal education or practice it is just a fact in some context without reflecting what is in hand. The doctor’s intuition will be right and often arrived without conscious thought, asking them to explain in detail may prove counter effective, in some case make the doctor doubt their judgement and end up treating poorly.

Let us take a few other examples from other domain. If you have come across the Monty Hall problem, where a host in a game shows 3 doors to a contestant, behind 2 doors are goats and the remaining 1 door with a huge reward. Once a door has been chosen, the host will open a door which has a goat behind it and give the contestant an option to switch the door if they think they would have made the wrong choice. If we do not think deeply, we think the odds are always 1/3rd irrespective of switching or not. In reality the odds are 2/3 if you switch and that has even stumped degree holders in math.

Photo by Pavel Danilyuk on Pexels.com

Another counter intuitive one is bank teller queue management. I read at this blog, which mentions that an average five hour waiting time to service a customer can be reduced to 3 minutes to just by adding one teller extra. That is 90x productivity jump by doubling cost yet a lot of decision makers won’t believe the expert who analyses the situation and recommends them the solution because it does not make sense for a non expert. The example is dramatic but can happen in real situations as well.

When I observe a lot of people with expertise, their unconscious competence helps them navigate with ease without even thinking about it. The moment you question their judgement, their instincts take a back seat and suddenly their competency goes down. I was at a restaurant, I requested a cook for fried eggs. The cook asked if I wanted both sides to be cooked, and I said “yes, but don’t break the yolk”. The cook left out a nervous laughter and when turning the eggs to the other side, the yolk broke. I disrupted the cook’s flow just by doubting their ability.

This happens frequently at work. Decision makers who are expert beginners often want to get into the details, what this does is, it interrupts the flow mode of expertise. Explaining the solutions and decision making process which would otherwise be unconscious nature, requires a good deal of effort and often leads to sub optimal solutions. If you have an expertise on some area and are tasked with solutions, then keep in mind that you have to explain your decisions to people who know details at a surface level. People are naturally curious and LLMs feed their curiosity a great deal.

Photo by Julia M Cameron on Pexels.com

For this reason, whenever I come up with solutions, I make it a multi step approach. This is I learnt from many different sources which help you harvest your unconscious competence.

Step 1 – Read the problem statement, re-read and think very hard to solve the problem. Too often no solution emerges, but all of a sudden when you are at a break, a solution emerges and when it happens immediately write it down. Beware, this solution is ephemeral and its details vanishes within a few minutes. Keep noting down the solutions that pop up at odd times like driving, cleaning etc.

Step 2 – Find reference material from internet and previous assignments to back your solutions. If it is a novel solution, dive deeper to explain but do not change the solution because you can’t find explanations.

Step 3 – KYEB (Know Your Expert Beginners) and be equipped with ELI5 answers to anticipated questions to impart confidence of the solution.

Before presenting your solution, establish your credentials which helps setting the right expectation using info from the KYEB research. This helps to present your views as an expert without getting into a loop of explanations and doubts. For the doctor’s case I discussed at the beginning, I recently see a few doctors have a dossier to quickly explain their decisions and cut short the questioning from the patients. We also will be expert beginners at many topics, the best we can help there is to let the experts do their job.

I was connecting with an executive who wanted a certification program for lead developers to become architects. I wanted to understand the intent behind this and asked why are not they able to grow into their roles without a heavy weight training. His answer was, “If a nurse assists a surgeon in 100 surgeries, will the nurse be eligible to become a surgeon without being trained and certified as a surgeon?”.

It was a nice try, but in reality how many nurses have become a surgeon. All architects are developers, they always grow from being a developer into an architect. It is never a comparison. This also brings the question, is an architect a developer even if the architect does not write code? Yes; to start with, a solution with no custom code is the best code ever written. Having said that, code is the blueprint of an application and anyone impacting the blueprint is in an architect or a developer.

Photo by Christina Morillo on Pexels.com

Software industry is plagued with under training of developers with architecting skills especially softer skills like communication, time management, negotiation etc. Instead almost all focus is given to develop their coding skills to act as a replaceable coding unit who will unquestioningly pick up a task assigned and take it to completion irrespective of what the impact it will create. This defocus removes the developers from being aware of the domain, work with business/product to suggest alternatives.

Whenever I onboard trainees or juniors into my teams, I spend the extra effort to push them to see themselves as an architect. It looks like a formidable uphill task for them, most of them are quick to adapt, catapult their career and have a fulfilling experience. I too benefitted from this attitude by my lead very early in my days. I was told to ask for measurable business results on whatever task I was about to pick as a developer, that one question acted as a guiding light.

Every developer is an architect, every architect is a developer. It is just the experience that varies, it is not akin to nurses becoming doctors when they gain experience.

I started my career with a waterfall style development taking a finished product after extensive quality control to the customer. Release was a major event, marked in our calendar where no one can take days off and the weekends are taken for granted that you will be at work. People spent a considerable amount of time on go/no-go calls and then a marathon effort to make a release happen. The releases were also followed up by hotfixes, bugfixes and minor enhancements which took a toll on the people making it happen.

We think waterfall is extinct now but it is not. There is still a great fear in releasing software to end users. We have progressed so much in software development that a lot of boiler plate is getting taken care by frameworks/tools, extensive automation capabilities help remove toil, abstractions and off the shelf components make it possible to develop and deliver something in matter of days and weeks not in months and years. Combine this with tech practices advocated by XP, we have a very agile tech team.

Photo by Pavel Danilyuk on Pexels.com

No matter what agility comes in technology, the inertia from the business and the product always robs the advantage of agility especially in mid and large organisations. Product teams always want to put a finished product in front of the customer that will wow them, in reality software development never sees a finished product, you just stop giving updates. Tech teams are capable to ship smaller increments of product, in a great frequency in the order of multiple times a day. In a mature continuous delivery enabled team setup, every commit or merge can go to prod within an hour.

Should we call each deployment as a release then. Deployment is a increment to the software, release is a logical grouping of many increments. Branch by abstraction will safeguard existing functionality while new increments are getting delivered and it will be a matter of another small increment to consider it as a release.

I have worked with some teams where the lines blurred, there were only deployments and no releases. One such team had to revamp a user profile page which aimed to declutter the UX and make it more easy to use. The team put a toggle button to preview the under construction page on the current user profile saying “we are revamping the page and let us know how it is coming along”. The designer also asked for feedback from the end user by providing comment ability on the new screen. Along with the comments, analytics was also baked in the new page to learn from user behaviour. This led to super fast iterations of the design as the feedback was instant and from real customers who use the product every day.

Coming back to the inertia from the product to go with a release mindset, this rots the continuous delivery mindset and quickly the teams align to a release mode making it slow, effort intensive and tiring. Decouple releases and deployment, product evolution is supported only when you can iterate as fast as you wish.