As we welcome the new year, I’m reminded of a profound lesson from Rashmirathi, the epic poem by Shri Ramdhari Singh Dinkar ji.

In Mahabharat, Parshuram, angered by Karna’s lie about his lineage, curses him to forget the knowledge of the Brahmastra - the divine weapon - when he needs it most. Devastated, Karna pleads with his teacher to take his life, believing a warrior’s purpose is lost without the knowledge of Brahmastra.

But Parshuram teaches him the meaning of a true warrior:

English Translation:

"Knowledge of Brahmastra—what does it bring?

A true warrior doesn't rely solely on a single weapon.

A warrior is called great by creating new arts, crafting new creations, innovating new ideas, discovering new methods, new emotions, and staying inspired with fresh enthusiasm."

This wisdom holds a timeless lesson for us as software engineers. Relying on a single tool, language, or technology limits our potential. Growth lies in constant learning, adaptability, and the courage to innovate.

As we step into 2025, let’s stop defining ourselves by narrow labels like “Java developer”, “.Net Developer” or “AWS architect” etc. Instead, let’s focus on solving problems, mastering new skills, and embracing change. True engineers are problem solvers, innovators, and lifelong learners. They are Imagineers.

Here’s to a year of learning, resilience, creativity, and bold innovation. Let’s imagine, create, and inspire - together.

Happy 2025!

Share

For the 18th article of the newsletter, here are the 18 profound paradoxes that I read lately. Thanks to all smart people out there who wrote these smart words. Here you go, in no specific order:

1. Small Focus, Big Gains

2. Practice dumbness become smart

3. Heroes create victims

4. Asking for help is a sign of courage

5. Teaching is the best way to learn

6. Being interested in others makes you interesting

7. Seeking happiness makes you unhappy

8. The more you know, the less certain you become

9. The way to be safe is to never be secure

10. Pleasing everyone makes people hate you

11. Short term pain long term gain, short term gain long term pain

12. Step back to jump forward

13. Ease is a greater threat to progress than hardships

14. Big talk means little knowledge

15. It is easier to ask forgiveness than it is to get permission

16. If you don't decide for yourself, others will

17. To break the rules, know them well

18. Anybody driving slower than us is an idiot and the one driving faster than us is a maniac

It was early 1990s and my parents decided to put me in a boarding school. At 11yrs of age, it was tough for me to adjust in a new place away from my family. In the 1st year, I was on my own with no friends and very limited interactions in and outside class. My grades were poor. Something changed.

My class teacher gave me a responsibility. I had to weekly update the class notice board with interesting snippets from the weeks’ newspapers - like fun-facts, ‘believe it or not’ etc. Remember, its 1990s - so no google, mobile, internet. The weekly summary had to be hand-written and in my own language. Updating the notice board every Monday gave me a sense of accomplishment. My interaction started with other kids of the class who shared interesting stories for me to put on the notice board. Looking at students reading what I had put boosted my confidence. My grades also started to improve.

This was an important lesson in life that I use in my teams for new joiners. Give them the notice board to update their snippets i.e. an opportunity to deliver something on the live product as soon as possible. This is the best you can do for any new joiner to get comfortable. Don’t wait for the person too long to get comfortable via trainings, reading documentations, dummy tasks etc. Give them something real and challenging, something that is actually required to be in the product now.

Higher expectation could lead to higher performance - Pygmalion Effect. It boosts their confidence, interactions with team increases, and they are no more seen as overheads. Of course, there has to be a mentor aligned - but now the mentoring happens on the real deliverable and not just on theoretical concepts or anticipated challenges etc.

The best place to start is by fixing a bug rather than building a new feature. This requires lot of reading and debugging of the existing code and flows. The fixes generally do not take huge time - so quick accomplishment. Requires higher interactions with other developers who built the feature.

Next time a person joins your team - remember the noticeboard - give an opportunity to put their snippet on the noticeboard!

Share

It was my father’s 70th birthday few days back. The family got together to celebrate the occasion. During some quiet time, I asked my father for his advice for living. For the 16th article of ‘ParsingThoughts’, here are the 16 lessons that he shared with us - covering health, parenting, career and life in general.

Take what you like and ignore the ones you do not.

Here you go:

1. Health First all things later. Health needs to be the top most priority. Nothing matters more than exercising daily.

2. Eat less. After 30 years of age eat only 70% of what makes you feel full. When you are 50 yrs reduce it to 50% of capacity.

3. Listen to your body. Prevention is better than cure. More the doctors you would visit more ill you would fall. Its your body, you understand it better than anyone else so take care of it.

4. Kids are your responsibility. Never outsource their upbringing to someone else. You can never overdo personal attention to kids.

5. Kids Education. Never cut corners on their education. Give them the best of the best education that your means allow.

6. Time. A busy person is always able to find time for important things in life, an idle person is never able to find time for anything.

7. Treat Perfection as a direction and not as the goal. Do not target for reaching perfection and loose sleep over it. Most of the time done is better than perfect. Its okay so long as you tried moving towards perfection.

8. Generate Wealth and stop when it starts consuming you. We must be ambitious and aim to generate wealth, succeed in our careers. More important is to know how much is enough and when to stop. Stop as soon as it starts to impact your health and family.

9. Forgive and Forget. Revenge, does more harm to you than the other person.

10. Do not take things personally. Let people say whatever they want - do not react. Maintain a smile. Stay out of arguments. This is one of the qualities he has observed in all people who were highly successful in their career.

11. Know what’s in your control and more importantly what is not in your control. If your environment cannot be changed do not stress rather adapt your self. That’s how species have evolved in nature.

12. Family over others. Outsiders will not help you in trouble times. Only family and close relatives would come to the rescue. Always stay in touch with them, help them and never break off from them.

13. Things happen if you really want them to. If you are determined enough, there is some kind of magic that happens and somehow things turn out the way you wanted them to be at the end.

14. Cooking. One must know how to cook. Cooking is something you cannot live without incase of emergencies.

15. Do your own work. Do not request kids to fetch water for you or your spouse to brew the coffee or make tea. This way you remain active. You like it when you do it yourself. More importantly one less reason to have a fight over.

16. Never be disrespectful to anyone. One must always be dignified in dealing with people. There would be times when you are unable to help or provide support to someone. But never be disrespectful. In hindi, he said, “Gud na bhi de sako per gud si baatien zaroor karo”.

Some years back a new rage had arrived on the scene - ‘the Spotify Model’. It seemed industry had found a new gem after years of ‘manthan’ with various processes and frameworks. There was a rush to adopt the model, suddenly teams became squads, groups became tribes, communities became chapters/guilds. Boom! Today, nobody talks about the model anymore, let alone adopting it. What happened?

Cargo Cult

Organizations realized adopting the model did not make them more agile, productive or profitable. What worked for Spotify did not work for them. Why?

To understand, let me take you back to early 1940s. During the World War II, as allied forces arrived on Melanesian Islands, huge amount of supplies were air dropped on these islands. Native dwellers were in awe of the military processes and the cargo that was air-dropped. World War II ended, allied forces abandoned the islands. Guess what, the islanders continued with the military practices they observed - mimicking the daily parades, using carved out wooden headphones, built airplanes with straws. Hoping that cargo will be air-dropped. Nothing happened. This is the origin of the Cargo Cult.

Mimicking Spotify model did not make other engineering teams super. We adopted the model without understanding the motivations and the constraints that made it successful in the given context. And were left with creating wooden headphones. We were all ‘Cargo Culted'.

Adopting a Framework

Hold on. What does it all mean? Do all teams need to devise their own processes. Do we all need to go through similar struggles. What about adopting best practices, what about not re-inventing the wheel, what about learning from others. Welcome to the world of frameworks!

Before I delve further on frameworks, let me give you 3 examples of famous Indian personalities. Virendra Sehwag one of the most successful batters in the world started cricket by imitating the God of cricket - Sachin Tendulkar. Sonu Nigam one of the most loved singers (especially for the 90s generation) became a a household name and started by copying the great - Mohammed Rafi. Shahrukh Khan copied the legend - Dilip Kumar early in his career. All 3 of them followed the styles of already established greats and then carved out their own niche that made them the new greats.

They all followed the Imitate, Assimilate, Innovate cycle. They started by following what was already working (Imitate), understood what worked for them and what did not (Assimilate), and developed their own styles (Innovate).

These personalities did not stay at the Imitate stage for too long and quickly moved to their own styles by which they are know today.

Coming back to software industry and the adoption of various frameworks, I have seen 2 flavors.

a) Teams either adopt an established framework and stick to it i.e. stay on the Imitate phase for too long. The problem arises when we stick with a particular framework irrespective of it helping the team or not leading to frustrations and fatigue in the team. Making team work for the processes rather than processes working for the team.

b) Some teams are skeptical of adopting a particular framework and start by creating their own processes and are in continuous flux of re-inventing the wheel many a times for the sake of ‘we are different’ syndrome i.e. staying only in the innovate phase. Leading to a confused team.

Pragmatic Approach

For any new team embarking on their journey in software development adopting an already established framework (that fits in the context) ‘to start with’ makes sense.

The keyword here is ‘to start with’. Frameworks are a great starting point. The frameworks come with industry best practices, provide new teams with a structure and guidelines to follow. Frameworks help the teams kick-start. But this is just the beginning of the journey and not the end. Teams need to keep their eyes open to see what’s working and why, what’s not working and why - Assimilation and then make the changes to the processes to make them work in the given context - Innovation. This is what made the Spotify Model work.

Conclusion

Avoid being ‘cargo culted’. Blindly following and sticking to a framework for the sake of it would leave us with the wooden headphones, straw planes and no cargo just like the Melanesian Islanders.

Frameworks do not deliver. Teams deliver. Adopt a framework that works for the team and not the other way. Ultimately, its the people who build great products!

References:

1. https://en.wikipedia.org/wiki/Cargo_cult#Pacific_cults_of_World_War_II

2. https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf

3. https://www.jazzadvice.com/lessons/clark-terrys-3-steps-to-learning-improvisation/

Today we continue to struggle with developing and maintaining distributed systems, while at the same time we have this seamlessly working, largest, scalable, flexible distributed system ever created - WWW. - The World Wide Web.

Remember 2020, when the lockdown happened and suddenly there was a surge in web traffic - with all people going online - schools, offices etc., the web continued to work seamlessly and ensured the show kept on going. What if we could design our software with same reliability and scalability?

"The Internet was done so well that most people think of it as a natural resource like the Pacific Ocean, rather than something that was man-made. When was the last time a technology with a scale like that was so error-free?"  - Alan Kay (pioneer of object-orientation, co-designer of Smalltalk) 

What makes Web work so well? REST provides an answer to it and can act as our guide to design any distributed system - that requires to be long-lived as the Web.

REST was coined by Roy T. Fielding in his PhD. dissertation - probably the most read one ever (who reads them apart from the writer and the evaluator ;))

1. REST is an Architectural Style for Web based Distributed Systems

2. Architectural Style is a set of constraints defined to retain specific Software Engineering Principles. We could implement different architectures based on an Architectural Style. Take a drive through Delhi or Agra you can immediately recognize the Mughal Architectural style by looking at any of the old buildings. While at the same time the architecture (layout, material used, aesthetic design) is different for each.

3. REST is built upon the constraints from existing Architectural styles with an additional set of new constraints. Constraints are a set of rules that ensure that the design meets the required expectations. For example, the constraints of safety regulations, cost, fuel efficiency are applied on the design of the car you are driving.

4. Constraints adopted in REST from other architectural styles include: Client-Server, Stateless, Cache, Layered system and Code on demand. These ensured the retention of software engineering principles - Separation of concerns, Reliability, Scalability, and Extensibility - in the REST architectural style

5. New constraints - to ensure uniform interface between components - differentiates REST from other Architectural styles. These constraints apply on Components (their role), b) Connectors (interaction between components) and c) Data (interpretation of data that flows between components). For example, in REST APIs the use of standard HTTP methods (GET, POST, PUT, PATCH, DELETE) to perform CRUD (Create, Read, Update, Delete) operations on resources identified by unique URLs ensures uniform interface for different clients to interact with web services.

The constraints - defined by REST Architectural Style, can help create components that are easy to understand, maintain, and use, and that can easily adapt to changing requirements or technologies. They also ensure that the components are scalable, reliable, and interoperable, which is essential for building large-scale, distributed systems.

I hope this article helped demystify some elements around REST.

References

1. Fielding, Roy Thomas. Architectural Styles and the Design of Network-based Software Architectures. Doctoral dissertation, University of California, Irvine, 2000.

Reminds me of a conversation I had 4yrs back with my younger one:

4 YO: Papa, how do we grow up?
Me: Son, you grow up by playing, eating healthy food, and learning
4 YO: No Papa, we grow up by celebrating Birthdays!

Just like my son thought birthdays make a person grow, some teams think following certain ceremonies makes the team agile.

According to me, ‘being adaptable’ is one of the core qualities that makes a team Agile.

What does ‘being adaptable’ means? Here’s a story from the greek mythology [I read in the book - Team of Teams by General Stanley McChrystal] to bring home the point.

King of Sparta - Menelaus and his men while returning home after 10 year long trojan war were ship wrecked on an island. In order to find a way out they had to defeat the old man of the sea - Proteus. Who could then guide them to the home.

The problem was that Proteous was a shape shifter and could take any form. The weapons Menelaus and his men mastered for a usual war would not help much.

The fight started, Proteous took different forms - of a lion, a serpent, a leopard, a pig, water, fire even a tree. Every time Menelaus and his men adapted as per the form taken by Proteus. They adapted - used legs to clinch the necks of animals, dug the fingers to control the tree branches, used arms to hold the fire…

Finally Proteus was defeated. Menelaus and his men were able to return home as they were able to adapt.

Living in a VUCA world, business problems could take any shape and form - just like Proteus. Successful teams are those that can adapt their processes, technology, and skills to address the specific problem at hand.

In my view ‘being adaptable’ is the true mark of an Agile Team.

Share

References

1. Team of Teams by General Stanley McChrystal

2. https://en.wikipedia.org/wiki/Proteus

Core Banking refers to the systems and processes that a bank uses to manage central activities that are carried out by banks, such as providing deposits and loans, keeping track of customer accounts, managing financial transactions, and processing electronic payments. These activities are typically carried out using a central computer system that is accessed by all of the branches of the bank, allowing customers to carry out transactions and access their accounts at any location. Core banking systems are designed to be scalable and flexible, so that banks can add new products and services as needed, and to handle large volumes of transactions quickly and efficiently.

In general, the core banking system is the backbone of a bank's operations and is responsible for enabling the bank to carry out a wide range of financial services for its customers.

What’s new in Core Banking?

There have been a number of developments in Core banking solutions in recent years, as banks have sought to modernize their systems and offer more convenient services to their customers. Some of the latest evolutions in core banking include:

1. Cloud-native core banking systems: These systems leverage cloud computing technology to host the bank's core systems and data, rather than running them on in-house servers. This can provide benefits such as increased scalability, reduced IT costs, and faster deployment of new products and services.

2. Open banking: This refers to the use of APIs (Application Programming Interfaces) to allow third-party developers to access and build on top of a bank's core banking systems. This can enable the creation of new financial products and services that are more closely tailored to the needs of specific customer segments.

3. Digital-only banks: These banks offer their services entirely online, without any physical branches. This can enable them to offer a more streamlined and convenient experience for customers, as well as potentially lower costs for the bank.

4. Advanced data analytics: Many banks are using advanced data analytics to better understand their customers' needs and preferences, and to identify opportunities for cross-selling and upselling.

5. Cybersecurity: As core banking systems handle sensitive financial data and transactions, it is crucial that they are protected against cyber threats. Banks are investing in advanced security measures such as machine learning-based fraud detection systems to help protect their systems and their customers' data.

6. Blockchain-based systems: Some banks are exploring the use of blockchain technology to improve the security and efficiency of their core banking systems.

7. Machine learning and artificial intelligence: Banks are also using machine learning and AI to improve the accuracy and speed of their core banking processes, such as fraud detection and customer service.

Challenges?

There are several challenges that retail banks are facing today, including:

1. Competition from non-traditional financial services providers: Retail banks are facing increasing competition from non-traditional players such as fintech firms, which may offer more innovative or convenient products and services.

2. Customer expectations: Customers are becoming more accustomed to the convenience and speed of digital services, and expect their banks to provide a similar experience.

3. Regulatory changes: Retail banks must keep up with constantly changing regulations, which can be costly and time-consuming.

4. Cybersecurity: Retail banks must protect their systems and customer data against cyber threats.

5. Managing risk: Retail banks must carefully manage risk to ensure the stability of the financial system and to protect their own interests.

What’s in it for Solution Providers?

Core banking solution providers can help retail banks overcome above challenges by providing a more efficient and flexible platform for carrying out core banking activities. They can also enable banks to offer a more seamless and convenient experience for customers, and to quickly roll out new products and services. Advanced data analytics capabilities can help banks better understand their customers' needs and preferences, and to identify new opportunities for growth. And robust cybersecurity measures can help protect against cyber threats.

Some factors to consider when evaluating cloud-native core banking solutions include:

1. Scalability: The solution should be able to handle a large volume of transactions and support the bank's growth as it adds new products and services.

2. Flexibility: The solution should be able to easily adapt to the changing needs of the bank, and allow the bank to quickly roll out new products and services as needed.

3. Security: The solution should provide advanced security measures to protect against cyber threats and ensure the safety of customer data.

4. Integration: The solution should be able to easily integrate with the bank's existing systems and processes.

5. Cost: The solution should provide a good value for the price, with a total cost of ownership that is reasonable for the bank.

PS: Experimented with ChatGPT to come up with this newsletter :)

Share

For today’s newsletter, sharing my notes taken during a session attended 2 years back on ‘Situational Leadership’. If you are a people manager, these notes may come in handy.

Situational Leadership

We commonly speak or hear the phrase ‘different strokes for different folks’. This guide is more about ‘different strokes for same folks’. Think of the classic skill-will matrix (introduced in Tao of Coaching by Max Landsberg). We tend to compartmentalize people in the 4 quadrants. The reality is that the same person can be in different boxes at the same time depending on the goal/task at hand.

For me, the below guide has come in handy especially when a direct report transitions into a different role.

Here’s the quick reference for you to start.

1. Diagnosis of Development Level: Identify Skill and Will (varies for each Goal for the same person)

   • D1: Low Skill, High Will [hopeful, inexperienced, excited, optimistic]

   • D2: Low to Some level of Skill, Low Commitment [overwhelmed, confused, demotivated, flashes of competence]

   • D3: Moderate to High Skill, Variable Commitment [capable, doubtful, insecure, bored]

   • D4: High Competence, High Commitment [confident, expert, consistent, self-reliant]

2. Leadership Style based on Diagnosis

   • S1 for D1: High Direction, Low Support [Defining, Telling how, Planning, Monitoring, Giving feedback]: I decide

   • S2 for D2: Low Direction, High Support [Asking, Encouraging, Praising, Redirecting]: We discuss, I decide

   • S3 for D3: High Direction, High Support [Encouraging, Asking, Appreciating, Reassuring. Problem solving]: We discuss, You decide

   • S4 for D4: Low Direction Low Support [Empowering, Challenging, Trusting]: Keep me informed

• Pitfalls to avoid

  • A person at a Dx will always remain a Dx

  • Believing Confidence is Competence: Ask: Pls tell me how will you do it?

  • Diagnosing Potential rather than performance

• Tips

  • Soft on People, Tough on Performance

  • Manage Behavior, Not the person

  • Regular 1o1 for proper diagnosis

I hope you found this quick start guide useful. Please leave a comment to share your thoughts on the post

Leave a comment

If you like the post do share it with your family and friends.

Share

PS: If you are wondering what ‘Julley’ means - this is the word I learnt during my summer vacation in the beautiful Ladakh region. People in Ladakh say ‘Julley’ to greet each other, same word is used to say hi, say bye, to say thanks. I loved the word! Here’s a pic from the trip.

Few months back, I was meeting a couple of energetic graduates who had joined our organization, embarking on their career. During the interactive session, one of the graduates asked - “what is that one thing you would recommend us to be successful in our career”. I said, think and act like the Principal and not the Agent.

Narada vs Garuda

To bring home the point, this is the story I narrated to the graduates (read in Business Sutra book by Devdutt Pattanaik).

Lord Vishnu decides to have Garuda’s (lord Vishnu’s carrier) statue placed before his in the temples. Sage Narada, being the staunchest devotee of lord Vishnu, is upset on Garuda being chosen instead of him. Naradaji decides to confront lord Vishnu. As he starts pleading his case, there is a loud sound outside the palace. Below is the interaction that happens:

Vishnuji: Naradji could you pls go out and see what happened?

Naradji (follows as said and comes back): Vishnuji there is a milk seller, she slipped on the wet floor

Vishnuji: Oh, I hope she is not hurt...could you pls check

Naradji (goes out and checks): No she is not hurt

Vishuji: I hope she did not incur any loss...

Naradji (goes out again to evaluate):...

As this was happening, Garuda arrives at the scene and then goes to Lord Vishnu - mentioning that there is a lady who comes daily from her village in our palace to sell milk she slipped on a wet floor, she is not hurt but has her pot broken and milk spilled allover. I have compensated her for the loss and asked the guards to drop her back to her village. Cleaners have been requested to wipe out the mess.

Vishnuji now looks at Naradji, who, without any further questions/clarifications understands why Garuda has been chosen over him and returns home.

In the above story, Vishnuji is the principal, Naradji is the agent, and Garuda is the agent who acted like the principal.

Principal-Agent theory

“If you want it done, then go. And if not, then send.”

-Julius Caesar

Employer-employee, lawyer-client, buyer-supplier are some examples of principal-agent relationship. Principal is the owner who delegates the work to Agent to act on their behalf. A principal would care for the business and do their best whereas an agent would not care as much as the principal and would act in their own interests. Principal has their skin in the game whereas agent does not. Agents act in their own interests rather than in the interest of the principal with principal not having enough information to monitor the agent activities.

Lack of understanding of this problem could lead to disasters - take for example Sears Holding Corporation - 120+yr old organization - largest retailer in United States in 1980s. It was once Walmart’s main competitor. Down the line, various division leaders (agents) competed with each other in their division’s interest rather that the organization as a whole. For example, the appliance division was selling and placing non-sears product more prominently in the stores as they led to better profits - though overall organization profitability took a hit. Obviously, Sears Holding Corporation ultimately filed for bankruptcy in 2018.

“If you do not understand the principal-agent problem, you will not know how to navigate your way through the world. It is important if you want to build a successful company or be successful in your dealings.”

-Naval Ravikant

Power of Incentives

Organizations, include MBOs, ESOPS etc. in the compensation structure to have employees aligned with the organization objectives. This ensures employees incentives are same as employer’s and they act to maximize their incentives which in-turn is in the interest of the organization. Having the right incentives is the key to solving the Principal-Agent problem.

Quoting two cases on the power of incentives - as mentioned by Charlie Munger in his famous 'Psychology of Human Misjudgment' speech from 1995:

Misplaced incentives

“Early in the history of Xerox, Joe Wilson, who was then in the government, had to go back to Xerox because he couldn’t understand how their better, new machine was selling so poorly in relation to their older and inferior machine. Of course when he got there, he found out that the commission arrangement with the salesmen gave a tremendous incentive to the inferior machine.”

Power of right incentives

“The integrity of the Federal Express system requires that all packages be shifted rapidly among airplanes in one central airport each night. And the system has no integrity for the customers if the night work shift can’t accomplish its assignment fast. And Federal Express had one hell of a time getting the night shift to do the right thing. They tried moral suasion. They tried everything in the world without luck. And, finally, somebody got the happy thought that it was foolish to pay the night shift by the hour when what the employer wanted was not maximized billable hours of employee service but fault-free, rapid performance of a particular task. Maybe, this person thought, if they paid the employees per shift and let all night shift employees go home when all the planes were loaded, the system would work better. And, lo and behold, that solution worked.”

As expected, the employees moved as quickly as possible to complete the job so they could go home early. Transfer times improved, and the solution was a success at FedEx.

Being successful at work!

As an employee, the way to success is to behave like a principal. When in dilemma, think what a person with skin in the game - the principal - would do. Act like one.

This is one of the keys to a successful career and to ultimately become the principal!

References:

1. Business Sutra by Devdutt Pattanaik

2. The Almanack of Naval Ravikant

3. https://fs.blog/great-talks/psychology-human-misjudgment/

4. https://www.versobooks.com/blogs/4385-failing-to-plan-how-ayn-rand-destroyed-sears

This issue of newsletter is a Tehri of different ideas and concepts I learnt this week. Here we go.

1. To be (Cloud) or not to be (Cloud)

In 2020, enterprise spending on Cloud ($130B) surpassed that on datacenter hardware and software ($90B) by a huge margin. As new organizations embark on the journey, the obvious efficiencies in operation and economics drive the adoption of cloud.

While many organizations are still catching-up on this migration towards cloud, a reverse trend - called Cloud Repatriation has already started. Repatriation results in one-third to one-half the cost of running equivalent workloads in the cloud. Dropbox, for example, moved away from cloud and was able to save $75M. As organizations scale, growth tapers - the spending on cloud starts to pinch and moving to on-prem is way to reduce the pressure on margins.

For any SaaS based organization continuous focus on optimizing infrastructure spending and creating portable solutions (flexibility to run on Cloud and On-Prem) is the key.

Read the insightful article for more details here.

2. Two German words

I came across two new German words this week.

A) Schadenfreude

This great book on decision making- Thinking in Bets: Making Smarter Decisions When You Don't Have All the Facts mentions the word Schadenfreude: deriving pleasure from someone else’s misfortune. The book says, “engaging the world through the lens of competition is deeply embedded in our animal brains… A lot of the way we feel about ourselves comes from how we think we compare with others…”.If someone we view as a peer is losing, we feel like we are winning by comparison and vice-versa.

We need to be aware of Schadenfreude - this mindset of zero-sum game we all carry could become a roadblock in our learning and a source of constant anxiety.

B) Auftragstaktik

I learnt this term from the book Superforecasting: The Art and Science of Prediction. The origins of the term come from War/Military, Auftragstatik is a principle where commanders were to tell the subordinates what their goal is but not how to achieve it. “Never tell people how to do things. Tell them what to do, and they will surprise you with their ingenuity”.

We see the same principle as the backbone of various agile methodologies like scrum - Autonomous teams. We as leaders need to empower our teams to take the decisions - provided we have been able to deliver a vision - that all team members strive to achieve together.

That’s all for this edition. If you liked it, please do share with your family and friends.

Share

“It is twice blest; It blesseth him that gives and him that takes”

William Shakespeare wrote the above lines as part of ‘the quality of mercy’ speech in Merchant of Venice. I observe, there are conversations that also possess the same quality. Today’s issue is an ongoing collection of such conversations with my kids - the ‘twice blest’ conversations. These happened at different times in last two years - you would find the ages mentioned varying accordingly.

On Life

1. My kids' school uses colored stars to report student's performance in different areas. Gold color: Excellent, Silver: Good, Purple: Fair.

   Excerpts of a conversation between my kids:

   8 yo: Yay! I am so happy I got all Gold stars in the report.

   4 yo: What's there to be happy about, you just got one color. I have got 3 different colors. Mine is better as it is more colorful and looks beautiful!

   What a perspective - one should positively take the feedback (rather feedforward). Just like my son's report, life is more colorful and beautiful if you have challenges to work upon! Though, the trick is in choosing the right challenge.

2. While narrating story of Mahabharata to 4yo:

   me: Pandavas were good and Kauravas were bad

   8yo (overhears): No Papa, Panadavas were also bad...(mentions 3 instances back to back)

   Me (dumbstruck): ...

   4yo: Papa you don't know anything...I am going out to play...

   Reminder for me…dump the engineering mind that thinks in binary and apply the MBA mind - its never black or white, but always a shade of grey

3. 6 yo: Papa, can we get upgraded?

   me: What does upgraded mean to you?

   6 yo: The characters in our computer game get upgraded

   me: What happens when they get upgraded?

   6 yo: They change, become strong

   me: Yes, we can also get upgraded

   6 yo: How can we get upgraded

   me: By learning and doing new things

   6 yo: So I cannot be upgraded, as I have a schedule to follow each day. I cannot do new things

   me: You can do new things within the schedule, you have a playing schedule - but you can try playing new games

   6 yo: Okay. Like we have fixed school schedule but we still learn new topics every day

   me: Yes, you got it.

   6 yo: Bye, I am going to ride my upgraded bicycle

   me (Thinking...)

   Thanks son! The conversation did rang the bell - am I following the same old/safer ways of doing things or trying new stuff - experimenting - am I upgrading myself?

On Agility

1. 4 yo: Papa, how do we grow up?

   me: Son, you grow up by playing, eating healthy food and learning

   4 yo: No Papa, we grow up by celebrating Birthdays!

   This chat with my 4 yrs old son reminds me of several interactions I have had with managers when they say we are agile as we follow certain ceremonies like daily stand-ups, retrospectives, demos etc. rather than focusing on the intent - team empowerment, collaboration, and continuously adapting to change...

2. me (to 6 yo): Why do you always pick only this particular pencil when you have so many others in your box?

   6 yo: I pick this one as it is the smallest.

   me: Why do you pick the smallest one?

   6 yo: Being smallest, it will be the 1st one to finish.

   me: Why do you want it to be finished early?

   6 yo: So that I can add a new pencil in my box soon!

   This conversation reminded me an old lesson on agility - Value is in completing open tasks not starting new ones!

Being Human

1. me (to 5 yo): Each person is special...and so are you - unique and no one in this world is like you.

   5 yo: "Kuch zaada nahi ho gaya"...

   me (coughing): ...

   How important it is to be at peace with yourself and accept the way you are.

2. 9 yo (reading natural vs man-made resources): Papa, why was everything made by man and no woman made any resources.

   me (surprised): Why do you say that?

   9 yo: My book says so, its either natural or man-made

   me: Aha, man is used by the book used to represent humans and not just man as in males…

   9 yo: Oh, I got confused. They should rather write human-made and not man-made

   me: I agree son, when you write your exams use human-made instead of man-made

   Felt proud of the question my son raised…seems somewhere we are laying the right foundation.

Save your bandwidth from all other activities this weekend and spend it on high signal communications with your kids. These are the communications that are twice blest!

That’s all for this issue of Parsing Thoughts newsletter. If you enjoyed reading, do share with your family and friends.

Share

Leave a comment

“No one achieves complete success in life; but even partial fulfillment is attained by but a few. Unfulfillment, the Mahabharata tells us again and again, is the normal condition of man.”

My fascination with Mahabharat and its characters led me to reading of the book ‘Yuganta: The end of an epoch’ by Irawati Karve last week. What an experience it has been. The book humanizes the demigod characters of the epic (Indian tradition actually considers Mahabharata a history). Each having their own anxieties, fears, struggles, moments of joy. Just like us they all had shades of Grey and were not all Black or White. The book provides a link to relate ourselves with the characters of Mahabharata.

One of the characters in Mahabharata that always intrigued me is that of Karna. I always felt pity for him. He was one of the best warriors, was big-hearted, apparently did not do anything wrong in his life, why then did he suffer so much, why was life so unfair to him, why was he not celebrated as other heroes. Why?

At least, this is what I thought until I read the book. The essay on Karna clarifies the whats and whys of his situation.

“He struggled all his life to gain what he thought was his rightful status and his bitterness lay in not having got it.”

As I understand, Karna was a classic case of ‘Backwards Law’ - as explained by philosopher Alan Watts:

“When you try to stay on the surface of the water, you sink; but when you try to sink, you float’ and that ‘insecurity is the result of trying to be secure.”

The Karna Syndrome

Karna spent all his life living in the ‘insecurity of trying to be secure’. He would have been able to achieve more significance had he come to peace with his situation - his own individual self.

Karna was caught in the vicious grip of the question “Who Am I?”. The question that Karna struggled with 3000 yrs ago still is the one all of us struggle in today’s times. In many ways, I feel majority of us today constantly undergo the same feelings (me of course). We are all Karna’s of the 21st century.

In the book, Irawati Karve beautifully articulates it below:

“All through life one is constantly asking, and answering the question: ‘Who am I?’ This ‘I’ remains dynamic and changeful; and so at no given moment is a final answer possible. Small children, to start with, often refer to themselves in the third person. The awareness of ‘me’ is linked with the awareness of ‘mine’. This is my mother, my father, my toys, my house,, and ultimately the ‘I’ emerges as the centre of all these possessions. This awareness becomes sharpened through families and social relationships. As the boundaries of the ‘I’ broaden, the ‘I’ comes in contact with the ‘not I’, the ‘you’ or the ‘he’, and also their expectations regarding the ‘I’. And these are the expectations which shape the various manifestations of the ‘I’.”

As I see, the answer to ‘Who am I’ can be achieved by developing self-awareness. Organizational psychologist, Tasha Eurich explains in her book ‘Insight’ that self-awareness is the meta-skill for the 21st century.

“Self-awareness is, at its core, the ability to see ourselves clearly - to understand who we are, how others see us, and how we fit into the world around us.”

Key to self-awareness is to have a clear understanding of the principles by which we want to lead our lives - the Values. Values provide the yardstick to measure ourselves and others, guide our actions, help make decisions…

This is where Karna missed the plot. All through his life he is a confused person. He also tended to go to extremes both in evil deeds as well as his good ones. This all could be attributed to him lacking in understanding of right set of values and hence self-awareness and in turn the un-answered question - Who am I?

I call it the ‘Karna syndrome’.

Note to myself

To all of us - Karna’s of the 21st century, wanting to come out of the shackles of the Karna syndrome - go ahead and do this immediately - understand, prioritize and adopt the right values**. These would act as the guiding principles - the yard stick to measure ourselves - creating self-awareness. Thereby getting close to answering the question ‘Who Am I?’.

**Refer to the book Insight and The Subtle Art of Not Giving a F*ck to help you get started with the right values.

Reference

1. Yuganta: The end of an epoch by Iravati Karve

2. Insight by Tasha Eurich

3. The Subtle Art of Not Giving a F*ck by Mark Manson

4. http://www.brooklyntherapist.net/blog/2018/6/12/alan-watts-backwards-law

4. Eustress

   Accounts from the past till the latest research today, emphasize on the importance of right amount of stress that leads to peak performance for an individual or a team.

   Mahabharata (around 1000BC) talks about warriors being taunted by their charioteer to rouse them which lead to better performance in battle.

   Medical research has discovered that for longevity and vitality - it is important that body is put under optimal stress - intermittent fasting, high intensity exercise, exposing body to uncomfortable temperatures kick-off the survival circuits in us.

   This optimal amount of stress called the ‘Eustress’ (coined by endocrinologist Hans Selye) leads to peak performance levels.

   We as leaders need to be aware of the what side of the curve our teams are and accordingly tune the stress knobs in the system.

5. The Flow

   All of us have been involved in the activities - that are so engrossing that we lose the track of time and the work gives huge satisfaction and sense of accomplishment. Such an activity we do just for the sake of it and not for any reward. The activity that continuously pushes you to move at a higher level of performance. That state is what the US psychologist - Mihaly Csikszentmihalyi calls the ‘Flow’ zone - having the right balance of Challenges and Skills that compliment each other.

   

   This zone is not a constant but dynamic - and one would self moving from one zone to the other - virtuous ones being Arousal-Flow-Control movements. Question to ask self what part of your daily activities are or can be moved into that flow zone by tweaking the two dimensions of perceived Challenge and Skill.

6. Task vs People

   I would recommend this model to be the first one to adopt for any person transitioning from an individual contributor to a leadership role.

   When I moved from an individual contributor to the team lead role - all my interactions with team members were around the task at hand. I would start to talk on other aspects of an individual’s life but my intention and thoughts back of the mind were always to know about the task the individual was working upon - is it on track, are there any challenges etc. etc. Such orientation does not take you far - especially in the knowledge industry.

   

   More than 10 yrs now into leading teams, what I have come to realize now is that as you move up, humanizing the interactions is the key. Be genuinely interested in people’s aspirations/career, their likings, hobbies, fears, family. And if you do this well work will itself be taken care of.

Reminder, mental models, just by reading about them would not help. Put them into practice and experience for your self.

Do share which mental models work for you.

References:

1. Yuganta by Irawati Karve

2. Lifespan by David A. Sinclair with Matthew D. LaPlante

3. https://www.ted.com/talks/mihaly_csikszentmihalyi_flow_the_secret_to_happiness

4. Flow by Mihaly Csikszentmihalyi

This issue is Part 1 of the series of posts I plan to share. It includes the mental models that work well for me, the ones that I would like to adopt or learn more about.

Without much ado, lets get started - in no particular order.

1. Eisenhower Matrix

   Feeling overwhelmed. Not enough time to think and work on important tasks. Eisenhower matrix comes to the rescue. This is a Tool created by 34th US President Dwight D. Eisenhower. He was also the Supreme Commander of the Allied forces during WW2.

   Trick: Categorize the tasks at hand on 2 dimensions - Important Vs Urgent. Then use the below guide to come out of the clutches. I have tried to make the guide as self-explanatory I could manage.

   

2. Dunning-Kruger Effect

   Helps understand how well you understand something or where are you in your learning journey on a topic :). Confused - You might have heard people saying these statements - “Incompetent people think they are much better than they actually” are or the corollary: “The more you know, the more you know you don’t know.” I have seen this happen very often when learning a new topic - one tends to think they have become ‘know it all’ in one go. This tool helps us to avoid overestimating our knowledge as well as avoid getting anxious if results take time to show up.

   Trick: Try to differentiate local maxima from global maxima. Non-math folks if the previous sentence did not make sense - do not worry. Please refer to the below guide.

   

3. The Knowledge Pyramid

   Continuing on the topic of “knowledge” from 2nd Mental model above. This “Knowledge Pyramid” is explained in the book: “Fundamentals of Software Architecture” by Mark Richards and Neal Ford. Anyone interested in moving towards Architect Path this book is a must read.

   We have been talking since ages on different levels of knowledge required to be successful in Developer vs Architect roles. This mental model helps in understanding the difference using the dimensions of Depth and Breadth of knowledge and is useful for anyone transitioning from Developer to an Architect role. Take a look below.

   

Hope you like the new series on Mental Models. Part 2/n would be coming soon. Do share your thoughts - it will help me include more relevant content in the newsletter.

PS: The drawings you see have been created using Excalidraw. Try it. Its awesome!

References:

1. https://fs.blog/2013/04/eisenhower-matrix/

2. https://www.talyarkoni.org/blog/2010/07/07/what-the-dunning-kruger-effect-is-and-isnt/

3. Fundamentals for Software Architecture by Mark Richards and Neal Ford

One of the several micro confidence boosters [will talk about those in another post] that ultimately led me to name that phase as ‘99highs - was me solving Ages of 3 children problem while many students gave up citing insufficient information. 21 yrs on, solving this puzzle with my 10yo - I realized managing uncertainty is the learning that this problem imparts [before reading any further, I recommend you try to solve the problem].

Here are my learnings how individuals and teams can deal with uncertainty. I am myself trying to adopt them.

1. Do not try to eliminate uncertainty: Learn to embrace it instead. You are not alone facing it. Our education system has led us to believe that life is a game with defined scope and specific rules to win else you loose. Life is a different game - there is no defined scope and rules change continuously - just playing the game is winning and there can be multiple winners. Accept it.

2. Take the First Step: Stop thinking and start doing. Take the first step with whatever information you have. Then take the next step, and next, and next. Do not freeze yourself thinking about the whole rather figure out the things as you go along. "I am not discouraged, because every wrong attempt discarded is another step forward. I haven't failed - I've just found 10,000 ways that won't work." – Thomas Edison.

3. Its a Terrain not a Tunnel: The steps you take to move forward are not always linear. Try out different paths - pickup new skills, try out new things you may never know how they would connect in future. As Steve Jobs said: “You can’t connect the dots looking forward you can only connect them looking backward”. Trust that dots will somehow connect in future and move on.

4. Systems over Goals: Focus on systems and goals will follow. Netflix would not have reached where it is today had it just focused on a specific goal. Rather they had a system in place which was to have best of the best talent in the organization [they refer to it as Talent Density] - and the results [exceptional Growth, engaging Content, state of the art Engineering] automatically took care of themselves.

I hope you did try to solve the Ages of 3 children problem - if not, go back try it.

Though Math is about being certain, solving the puzzle did help me with lessons on dealing with Uncertainty.

Hope you felt the same!

References:

1. Loserthink: Scott Adams

2. Atomic Habits: James Clear

3. No Rules Rules: Reed Hastings, Erin Meyer

‘Management by Metrics’ does more harm than good. I will talk about three of the many such metrics used in software development — calling them ‘Cobra Metrics’ — that actually are detrimental to the purpose they are used for.

Before that, let me take you back to the British Rule in India. To control the snakes population in India, the British authorities at that time initiated a program that rewarded any person who brings in a dead Cobra. This program, after initial success, led to a reverse effect — as people started breeding Cobras to get more rewards — thereby leading to an increase in snake population — much higher than it was before the program. This reverse effect of a policy is called the Cobra effect.

The same Cobra Effect can be observed in software development when we get too fixated about metrics numbers and start incentivizing teams based how they perform against those numbers. 3 of the many such metrics (Cobra Metrics) are:

1) Unit Test Code Coverage

One of the quality gates set by (for) engineering teams is >X% (80,90, 95…) unit test code coverage. Setting such targets leads to two common issues: (a) High Unit Test Code Coverage gives a false sense of good product quality and hence a tendency to ignore other tests (like integration tests etc.) thereby leading higher bug leakages. (b) In order to achieve high coverage scores, developers begin to write junk unit tests that target ‘petty functions’ with no business logic/algorithm. These unit tests in many cases become mere replica of the logic written in the functions being tested and require to be modified whenever implementation changes. Thereby, increasing the code surface area where bugs could occur and leading to additional maintenance.

So, instead of improving the product quality — too much fixation on Unit Test Code Coverage could actually lead to deterioration of the quality and making it a Cobra Metrics.

2) Functional Test Automation Percentage

Many teams’ efficiency is measured by the percentage of Functional tests that are automated. So much so that they establish a separate ‘Test Automation Team’ with the sole objective to automate functional tests. In my experience, such a strategy instead reduces the overall efficiency of the team. 

As the tests are automated by a separate ‘Test Automation Team’— this team also becomes responsible for executing and maintaining them. Such tests suites does not see the light of the day as they never get integrated in the Dev workflow — Devs tend to bypass the tests as they do not understand them or feel responsible to maintain them. The test suites are then always executed later in the cycle and at that time it is realized the use cases have been modified which requires updation of the tests. 

Despite Test Automation percentage getting increased, the overall team’s efficiency actually decreases— making it one of the many Cobra Metrics.

3) Velocity Variance

I have been a part of many such management reviews where questions were raised on the variance in Velocity with each sprint. This variation is a normal phenomenon — and ideally velocity is an average concept and to be used internally by the Dev teams. When velocity variance becomes a metrics with a target range, teams rather than inspecting and adapting from the velocity trends start either burning out to ensure the committed velocity is met or they start planning for lower velocity.

Velocity is a measure that helps team to plan better but when its variance starts being used as a measure of team’s commitment and estimation accuracy it becomes a Cobra metrics.

Conclusion

‘Management by Metrics’ is not bad — as the expectations are objectively defined — it helps in clear communication and measurement. Just defining the targets numbers without a clear understanding of the intent of using a metrics is a problem which could lead to more harm than good. 

Beware of such Cobra Metrics!

Have you encountered any Cobra Metrics in Software development? Please share your thoughts.

Title Photo Credit: My 9 YO.

Further Readings:

• https://rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf

• Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations

Two people Ria and Vicky (names changed), fresh out of college, join a software development organization in 2017. Both underwent the same selection process and then the trainings before starting their journey. In 2019, they are part of the same organization but performance levels are way apart. What happened?

Back to 2017, Vicky joined a development team working on big and complex product with various modules. The team had a well-defined processes - documented 'who does what', SDLC, KT, induction plan etc. More so, the team had even defined how and when a person progresses from a novice to an expert level in both functional and technical aspects. Just like any new person joining this team, Vicky was asked to follow the induction plan with specified timelines - overall, a 6 months time-period on the journey: functional knowledge->bug-fixing->small features-> autonomous developer on the product.

On the contrary, Ria joined a team working on a comparatively smaller product team with no defined processes. The team was already struggling to meet the commitments. Ria was given no induction plan to follow. Infact, she was expected to start contributing on team's deliverables with no KT whatsoever from day 1.

Two years later, in 2019, both Vicky and Ria are now part of the same team. Their is a stark difference in their approaches. While Ria is proactive and always looking to pick new and challenging stuff, taking complete ownership. Whereas, Vicky is comfortable working on known areas - work which is similar to the one he has done earlier or the one which is clearly defined in terms of what needs to be done with multiple follow-ups.

While there could be multiple factors at play here leading to different performance levels, one of the factors is what the experts call - the 'Pygmalion Effect'. The performance of an individual is impacted by the expectations that people have from him/her - higher expectation could lead to higher performance - this is known as Pygmalion Effect. This was the case with Ria. Where she was expected to equally contribute from day 1 in the team and she put in all the efforts to ensure she delivers and in turn comes out as a high performing individual.

The opposite is also true where lower expectations negatively impacts the performance of an individual. This is called the 'Golem effect'. This is exactly what happened with Vicky - who was not expected to immediately contribute but learn via following a defined induction plan. He continued to work to meet just those expectations and never challenging self more.

We as leaders need to be aware that are expectations from our teams/team members could impact their performances. This has a profound effect specifically on people just starting their careers.

Have you encountered Pygmalion and Golem effects in your careers? Please share your thoughts.

Pic Credit: My 10 YO

References:

https://hbr.org/2003/01/pygmalion-in-management

What are the risks in your project?

Risk Management in many Scrum projects is implicit. Frequent short releases, inspect and adapt takes care of common risks - Technology, Business and Financial. Scrum teams work with a myopic view - where the focus is on the issues at hand and not at the risks that could become issues later. This works well for small projects, involving one or two self-sufficient scrum teams.

For large and long running projects, with multiple scrum teams thereby having multiple touch points and dependencies, explicit risk management is required to involve right stakeholders at the right time for project success. Although important for project success, risk management is still considered a 'waterfallish' concept with no events focusing on 'Identifying risks'. In most cases this is left to the one or 2 people (product owner or sometimes scrum master - through Risk Adjusted Backlogs etc.) with ad-hoc inputs from the team during Release/Sprint Planning.

Here's an approach that could be built into the Scrum teams for better Risk Management - by involving all team members in Risk identification. I call it "Riskopective: Back to the Future'.

Like other scrum events, Riskopective is a time-boxed event (~30min) and performed at the start of the release/sprint - can be be chained to Release planning and (or) Sprint planning meeting to match the natural rhythm of team. These are conducted just like Retrospectives - facilitated by the scrum master, where team together reflects and contributes. Its an opportunity for the team to identify the project risks and plan to manage them but unlike Retrospective (where team looks back at the issues) team looks to the future and identifies risks that could become issues later.

The key element to Riskopective is a technique called 'Premortem'. This technique was proposed by psychologist Gary Klein and referred as one of the favourites of Nobel Laureate Daniel Kahneman. Here the complete team goes 'back to the future' - basically time travels and considers the scenario where the current project has failed (it could be a sprint, release or product). With this assumption (failed project), each team member writes down the reasons for failure. The responses by the team members would become the potential risks. The beauty lies in how the 'Premortem' technique encourages people to find flaws (an unpopular trait) in the plan rather than being highly optimistic and committed to the plan (general expectations of organizations). This turning of the table in particular plays the important role in shifting the myopic mindset to long term and involving complete team to identify potential risks in the project.

So the next time you are about to kick-off a project, release or a sprint, pls ask the team "let's go back to the future" (a famous line from my one of the favourite movies - 'Back to the Future')...

What is your opinion?

Do you think Risk Management is an important element for project success - even those following Scrum? What has worked for you? Please share your thoughts.

References

1. https://capitalallocatorspodcast.com/wp-content/uploads/Klein-Sonkin-and-Johnson-2019-The-Misuse-of-Premortems-on-Wall-Street.pdf

2. https://fs.blog/2014/01/kahneman-better-decisions/

3. https://hbr.org/2007/09/performing-a-project-premortem

Hello I am Varun Agarwal. Welcome to Parsing Thoughts newsletter on my learnings, experiences as an Engineering Leader, Software Development.

Sign up now so you don’t miss the first issue.

Subscribe now

In the meantime, tell your friends!