The Managing Leader vs the Coaching Leader!

Blog-Managing_vs_Coaching_63315415In Hindu mythology there are two great epics. One is called Ramayan and other is called Mahabharata. The centre story of both these books is around victory of good on evil. In one story Lord Ram leads his army to defeat Ravana in his land, While in the second Lord Krishna oversees Pandavas defeat Kauravas in the battle at Kurushektra.

In Ramayan, Lord Ram is the best yodhaa of his side. He leads his army from the front. Strategizes & directs different people to do things which will meet the objectives. His people are happy to follow orders & want to get all the appreciation for being the best executors. Lord Ram set direction & also tells people what to do during difficult times. Ultimately they won the war & the final outcome was achieved.

On the other hand Lord Krishna told Arjuna, I won’t fight the battle. I won’t pick up any weapon; I would only be there on ur chariot as a charioteer. And he did what he said. He never picked up the weapon & he never fought. Still, Pandavas won the war & final outcome was achieved.

ramkrishnaSo, what was different? It was their managerial style & it was also the type of people who were being lead.

Lord Ram was leading an army of ‘MONKEYS’ who were not skilled fighters & they were looking for direction. While on other hand,

Lord Krishna was leading Arjuna who was one of the best archer of his time. While Lord Ram’s role was to show it & lead from the front. Krishna played the role of a coach whose job was to remove cobwebs from his protégée’s mind. Krishna couldn’t teach Arjuna archery but he could definitely help him see things from a very different perspective.

Here are some of the basic differences in two styles:
Lord Ram : A skilled warrior, lead monkeys, was emotional, gave precise roles & instructions, motivated the army to fight for his cause

Lord Krishna : works with best the professionals, provides strategic clarity, allows team members to take lead, fights for the cause of the team, did not depict his true emotions


  1. Look at ur team/family & reflect what type of leader/parent u are, One who keeps answering/solving problems for people/kids Or Who asks relevant questions from their people/kids so that they can find their own solution.
  2. Are u someone who tells/directs all the time Or Someone who clarifies doubts & allows their people/kids to find their own ways.
  3. Are u someone who has monkeys in the team & the way u deal with it Or u have the brightest experts in their area getting stuck with issues?
  4. Younger generation doesn’t want you to tell or show how things are done, they want to know the meaning of their task and how it makes a difference in this world.
  5. They are Arjuna’s who don’t necessarily seek more skill/knowledge but they need someone to clarify the cobwebs in their mind, if u still apply Lord Ram’s style on them, u are bound to fail as a manager.
  6. On the other hand if there are people who aren’t skilled enough but rely on ur expertise to sail u through Lord Ram’s style is appropriate.

Isn’t it good for us to reflect & think what managerial style will bring the best result for u and ur team/family ? Is it Lord Ram or Lord Krishna?

The Managing Leader vs the Coaching Leader? 🙂


Agile Fatigue

In long running Agile projects there are observations that the productivity of the team(s) come down as they burnout. In the (bad) old waterfall days projects had ramp up and ramp down time which gave developers and team members some breathers but in the (good) new Agile days its sprint after sprint relentless teams hardly get time to catch a breath.

Agile Fatigue is more worse when you work with not so matured product owners, product management teams who thinks development teams as run machines and expect them to deliver sprints day in, day out without a break.

Some of the symptoms of Agile Fatigue includes user stories that drag from sprint to sprint, user stories that are too big or broken down inappropriately, lack of or improper use of epics, and QA/Test organizations falling behind because they are handed too much functionality all at once. Don’t let the team con you into waiting ‘until the next big function’ because it’s ‘too much trouble/delay/work’ to fix the problem immediately.

To help the teams overcome Agile fatigue , some of the industry practiced best practices are

  1. Ensuring the backlog is “just good enough” : Don’t waste time perfecting a list of product features or tasks that, by the nature of agile, is going to change over time. Start with an imperfect and still well defined backlog and transparent communication to keep anxiety and fatigue from building and know that the grooming and retrospectives will mature the backlog quickly and continue over time.
  2. Learning & Innovation Sprint: Make every 5th or 7th sprint lean and learn and innovate, in the sprint the team took fewer story points and committed to learning a new technology/trick , this kept the teams ticking.
  3. Plan hardening sprints : Give tech debt ownership to development teams and ensure we had planned hardening sprints where the team took care of upgrading frameworks/libraries, clearing technology backlog, refactoring quick and dirty hacks , fixing defects, fixing performance issues that piled up over a period etc.  This often gave the team a sense of technical ownership.
  4. Encourage and make Automation part of Sprints: Identify repetitive manual tasks as part of retrospectives and add stories to automate them. This keeps the Enthusiasm moving across the teams.
  5. Team Building/Reset Day – A fun day where the team creates working agreements/charters, builds trust and has fun. It is essential all teams do this as setting expectations when times are good will see you through the times when they are not.  Money in the bank so to speak.
  6. Sprint Retrospective Action items Folow UPs: Over a period, sprint teams gets bored and lose interest as they feel there are no takers to the action items discussed in the Sprint Retrospective meetings. Especially for long running sprint teams , this is more evident. Teams actually improve more often and quicker due to heightened transparency on Retro action items. Having the support from the Product Owner, Business Owners is very important, because it gives a clear sign that whatever the team agrees to improve upon is really important and should be solved!.

A more Optimistic CAN-DO Attitude without understanding the reality is more dangerous than a more practically approached attitude understanding and balancing the reality and yields more results 🙂