What can Aurangazeb teach MBA students?

Aurangzeb was the last Great Mughal Emperor, dying at the ripe age of 89 in 1707 AD.  Although the Mughal line would continue till 1858 AD with 11 more 'Emperors', none would ever rise to prominence.  Aurangzeb extended the Mughal domain to its greatest boundary, from Kabul till Assam, and reaching Kaveri basin in South India.   He was a brave warrior, fighting till his death many a battle, mostly successfully.

But historians generally consider Aurangzeb a failed emperor, as someone lacking a vision for the  future, who would damn the Mughal line forever.  There are many lessons from his life that can be applied to modern management practices.

At his core, Aurangzeb was a failed leader, although he won many short-term goals all his life.

Trust your partners

Aurangzeb was notoriously paranoid, not trusting his brothers, sons, ministers or even his own father.  At various stages, he imprisoned them, executed them or banished them, always viewing each as a rival power center.  This forced him to run all his campaigns as a solo champion.  From Akbar on, while no Mughal emperor had a cordial succession to power, Aurangzeb made things worse.

Lesson: Individual achievement will not lead to long-lasting organizational success, unless the leader shows trust in his deputies and takes effort to nurture each to his full potential.

Delegate and empower

Aurangzeb would not strengthen the forces even when is own son, Prince Muazzam, asked for reinforcement during the Deccan campaign, fearing his son would turn into a rebel against himself.   Not willing to delegate the responsibility, Aurangzeb would personally lead his Deccan campaign for 26 years, never again returning to North India.  He was reluctant to groom any successor even when he grew old.  When Aurangzeb passed away, there was no one with power to rule his domain effectively.

Lesson: The hallmark of a leader is his ability to create more leaders, perhaps someone who can even excel oneself.   Keeping the powers too centralized would distract the leader from working effectively.  Like his predecessors, had Aurangzeb delegated his Deccan campaign, he might have had time to consolidate his empire, saving it for his successors.  

Know when rules of the game has changed

Aurangzeb's lasting failure was against the Marathas, whom he would never subdue in spite of his dogged pursuits.  While Marathas initially had a charismatic center, Chatrapathi Shivaji, they quickly disintegrated into multiple factions, when Shivaji passed away in 1680 and his son Shambhuji was brutally tortured to death by Aurganzeb in 1689.  Marathas then took to plundering, moving in small teams for hit-and-run campaign against Mughals, with no central authority governing them.  Against these roving bands, Aurangzeb deployed his Imperial army, trying his old game plan on capturing forts on battlefield.  Even after decades of war, Aurangzeb failed to see that his Imperial Army was ineffective against the gorilla war of Marathas.  He was not a robust general to change his strategy in a fluid theater.  He never understood why he failed in his wretched Deccan campaign, dying a disillusioned old man.

Lesson: When the old and trusted strategy fails to work even after multiple attempts, it behooves the leader to dissect the situation to understand its root cause.  A leader should be agile and open-minded to think out-of-the-box, after first acknowledging the failure of his past efforts.  Not everything is a nail, simply because you have a hammer.

The perils of growing too fast

While Aurangzeb was a master empire-builder, he was a meek administrator.  His official writs were regularly ignored by his remote provincial governors.  Surprisingly, given his notoriety among historians, Aurangzeb was mild in dealing with Imperial officers for their disregard of his orders.  While Aurangzeb understood the importance of keeping his empire safe from external threats, he neglected to improve it.  Towards the end of his rule, only Bengal province under the governorship of Shayista Khan produced revenue for his central government.  Corruption and inefficiency was rampant in his administration, to his utter dismay.

Lesson:  Growth at any cost is a dangerous strategy.  Without a strong organic support to sustain the organization, expanding the organization for its own sake is bound to fail.

Address the Agency Problem

Aurangzeb's adversaries were regularly able to corrupt his forces, sometimes even his own sons,  to collude against his objectives.   In several instances, Mughal commanders simply bribed their Maratha counterparts to surrender the fort temporarily to get credit for victory - they even indulged in a bidding war among themselves.  In a particularly galling sham, Zulfiqar Khan, the Mughal commander sent to capture Rajaram in Gingee fort, simply chose to camp outside the fort to increase his importance in the Mughal court.  With his large force, Khan could have captured Gingee on the day of arrival, but he managed to drag the campaign out for 8 years, till he stormed the fort in 1698, even letting Rajaram escape.

Lesson:  As a project leader, ensure that all stake holders have a strong incentive for an orderly completion of the project.  Address the conflict of interest effectively before it manages to cripple the project.

Enjoy your work

Aurangzeb considered his role as an Emperor a sombre duty, to be executed meticulously without joy.  His self-control and simplicity in life were legendary.   His life stands in stark contrast with that of his forefathers, who regularly mixed business with pleasure.  Some of this drudgery was driven by his religious beliefs.   Aurangzeb's life became frustrating and dull and this affected his judgment towards the later part of his rule.

Lesson: Any task loses its luster, if executed mechanically.  A leader should be able to inspire his deputies to take pleasure in their work.  Quality of work suffers when the agent disconnects his heart from the work at hand.

Holding the Programmer accountable

Currently the software industry takes great liberty in shipping buggy code to customers.  Even when the buggy software causes economic harm to the end-user, the liability of the programmer responsible for the bug is limited.  In the worst case, the programmer may lose his job, but more likely he suffers just a reprimand. The software vendor that shipped the defective product may sustain a slightly higher liability, such as a loss of the contract, or intangibles like loss of its reputation or damaged brand-name.

When a medical professional causes damage to his clients, he can be held legally liable for the suffering caused.  When a building collapses because of poor construction, we can go after the builder for reparation.   When your defective toaster causes fire, the manufacturer can be held liable.  When the car seat-belt fails to function, its maker can be hauled to the court of law.

When quality failures bankrupt other companies regularly, what makes the software vendor get away with it?  To add insult to injury, software industry routinely ships product with known bugs.  It is acceptable for a programmer to sign off her work with known defects.  The defect identified just gets added to a growing list of bugs to be fixed in the next project cycle.

Why not expose the programmer to legal liability for the damages he caused?  Will this accountability result in improved software products?  

In [CACM April 2009 - A direct path to dependable Software], Daniel Jackson gives a brief survey of software related incidents covering hospitals to medical instruments, and talks about software companies actively suppressing even basic data on the number and severity of bugs in their products.  Can a civilized society accept such practices in any industry, leave alone one as crucial as software development? 

There are some moves now to hold the software industry more accountable.

Let us look at some arguments both in favor of and against holding the programmer legally liable for delivering defective product.

Point 1: It is impossible to deliver a defect-free software product of reasonable complexity ("Halting Problem").  Also, Quality Control testing cannot catch all possibilities.  As Dijkstra famously observed, software tests can only prove the presence of bugs, not their absence.

Counterpoint 1: Liability depends on what could be reasonably expected of the programmer.   If the programmer did not follow the prevailing industry standards and make all efforts to deliver correct code, he should be held liable.

Point 2: Bugs are acceptable trade-offs in software delivery.  Quality can be traded-off against cost or time.  If the bugs identified are deemed non-lethal, the software product can be shipped out.  Some bugs may not be even experienced under regular use, rendering them harmless.  Delaying the product to fix all arcane bugs will result in competitive disadvantage.

Counterpoint 2: While not all bugs need to be fixed before delivery, those that break any reasonable user expectation should be fixed.  Any bug that violates the letter and spirit of user requirements is deemed harmful.  Minimally the user should be made aware of any shortfall in writing and his consent obtained before releasing the product with the defect.  The developer should be confident that his decision to release the product with known defects will stand scrutiny in a court of law.

Point 3: Defects may not be foreseeable.  Software behaviour is heavily influenced by the run time environment.  It may be impossible to account for all variations.  The combinatorial explosion that would result in certifying the product with other vendor products is insurmountable.

Counterpoint 3: Software products should be driven by clearly defined specifications that identify the typical run time environment.  If an user is known to use a set of third-party software products, its acceptable interaction if any should be documented in user requirements.  As long as the programmer did not do due diligence in ensuring his product would work under expected use cases, she should be held liable.

Point 4: Penalizing the programmer is counterproductive.  No professional deliberately sabotages her own product.  This scheme will incentivize the programmer to search for legal loopholes to avoid liability, instead of coding to the best of her abilities.

Counterpoint 4: A programmer aware of her legal liability will be doubly vigilant in her work.   Under the current situation where the programmer is treated with kid gloves, code quality is likely to take a back-seat to other priorities.  

Point 5: A programmer is naturally oblivious to defects in his own code.  It is easy to miss bugs in one's own code, lacking a different frame of mind to inspect it critically.

Counterpoint 5: There is a plethora of tools at the programmer's disposal to help him track and fix the bugs: user sign off on specs, design review, following coding standards, documentation, code review, various test approaches (unit, regression, system, automated, user-acceptance).  Following systematic approach is known to result in improved quality.  Again, the programmer's legal liability will account for what could be reasonably expected of him, under the existing state of industry.

Point 6:  In an industry notorious for a shortage of highly skilled labor, such a burden will drive away prospective employees.   As it is, students do not sign up for computer science courses.  

Counterpoint 6:  In classical Economics, a reduced supply and increased demand results in higher price equilibrium, which will force more participants to enter the supply side.  Such supply side concerns should be addressed independently, such as government subsidies to students, and should not be used as an excuse for delivering shoddy work.   

Point 7: Market-driven conditions already ensure good software quality.    Forcing the programmer to buy insurance for his work will result in that cost being passed on to the customer.

Counterpoint 7: Studies show that the threat of legal liability for shoddy work results in the actors paying attention to defects.  A software product should be viewed as a contractual obligation to its end users, and as such be subject to contract law.  Markets determine what is an acceptable cost increase for better quality.

Point 8: Software is mostly a collective enterprise.  Rarely industry strength products are developed by a lone programmer.  It is difficult to identify the programmer responsible for the bug.

Counterpoint 8: As a starting point, the software vendor should be held liable.  As all the programmers have a vested interest in their firm avoiding legal liability, this will have the result in delivering better software product.  

Point 9: Open-source software is a labor of love, developed by enthusiasts without a financial motive.  Legal penalties will shutter this movement down.

Counterpoint 9: Legal liabilities should be ascertained only on commercial software products.  This will result in commercial firms underwriting the legal liability of strong open source products.  For instance, IBM already offers to cover legal liabilities of Linux from patent infringement suits.  This is a win-win situation: open-source is left alone, commercial firms fill the vacuum to provide legal cover and legal liability results in improved software products.

Point 10: Legal liability will result in stifling creativity.  Software industry thrives on innovation.  Fear of suits will freeze the developer's flow, resulting in contrived products.  Many products are conceived without an end-user specification, created by the vision of few creative minds.  

Counterpoint 10: All commercial products should satisfy certain reasonable requirements, unlike artworks which are deemed expressions of freedom.  In particular, software products that result in harming the society should be held liable.

Point 11: All first generation software products are bound to have bugs, no matter how much effort is spent to avoid it.  Products regularly improve on repeated iterations, from real-world experience.  Legal penalty for bugs will ensure nothing new ever comes out.

Counterpoint 11: This does not seem to be true from experience in other industries.  Car companies regularly introduce new models.  Medical instrument makers constantly invest in innovation.   Builders try new construction material all the time.  In all these cases, they are successfully operating under the threat of legal action for defective products.  It is difficult to imagine software industry would be an exception.

Summary: Holding developers legally liable for defective products is definitely on its way.   Software industry can ignore this at its own peril.

Honor killing or murder?

There are regular reports from the Middle East countries where a hapless victim, typically an unwed lady caught in an amorous episode, get stoned to death in public by a family member, in the name of Honor killing.   Sometimes these are justified invoking Sharia law, on religious grounds.  Many times, these killings are sanctioned by the law of land, after a court-trial.

These are similar to the medieval practices in India, where Rajputs regularly killed their women and children, when defeat was certain in their battles against the Muslim rulers.  Their women folks were regularly degraded by their Muslim conquerors, and their children rendered Eunuchs.  The proud Rajput warriors chose to kill their family members to protect their perceived clan honor. 

The idea of honor was pushed to extremes at times.  Previously in India, the Hindu widows were perceived to lose their place in the society and forced to terminate their lives on the funeral pyre of their deceased husbands. 

Historically, there has always been a trade-off: upholding one's social standing, even at the cost of self-injury, or accepting potential humiliation to live another day.  Sadly for most of the victims, this decision was made by their community.

From a selfish gene point of view, it is hard to justify such deaths.  All living beings have an innate sense of survival and rarely give up their rights to live.  To overcome this resistance to death, society sometimes dangles such carrots as going straight to heaven on death for the religiously inclined, or honor and pension for the victim's survivors, for the modern day soldiers.

Laws of all civilized nations permit killing only under the most extreme circumstances, where the victim's death overwhelmingly benefits the society at large.  No life is deemed so despondent to justify terminating it.   It is crucial not to romanticize those who killed their dependents under the guise of family honor, patriotism, love or religion. 

A woman who loses her honor may redeem it some day.  One who loses her life loses it forever.