Microfinance + Private Equity = Suicide Inducing Debt

Microfinance, the practice of giving small loans to networks of poor women that was pioneered by Mohammed Yunus, has been lauded by foundations and many liberals as a great example of “social entrepreneurship” – using markets to do good by attending to a triple bottom line. The idea has had a lot of success. But as an AP investigation has documented, it has alsolead to terrible tragedy – crushing debt burdens that, in a cruel distortion of the original idea, have led to the suicide of over 200 people.

In 1997, [Mohammed Yunus] acolyte Vikram Akula founded his own microcredit organization, Swayam Krishi Sangam, Sanskrit for “self-help society.” In 2005, SKS started operating as a for-profit company and Akula began chasing private investment to achieve the massive scale required to dent global poverty.

But in 2008, under the influence of a private equity firm, it started moving in a very different direction.

In October, Boston-based Sandstone Capital, now SKS’ largest investor, made a major investment. It joined U.S. private equity firm Sequoia Capital, which funded Google and Apple and is SKS’ largest shareholder, on the board of directors. Akula, who had been chief executive in the company’s early days, stepped down in December 2008 but stayed on as chairman. The company brought in new top executives from the worlds of finance and insurance. SKS also began transferring more loans off its books, selling highly rated pools of loans to banks, which then assumed most of the associated risk of borrower default. That freed SKS to push out more and bigger loans.

In December 2009, SKS launched a massive sales drive. The “Incentives Galore” program ran through February 2010 – just one month before the company filed its IPO prospectus.

Agents won prizes worth up to 10 times their average monthly salary for signing huge numbers of new borrowers. Vautrey said he coordinated the shipment of 8,800 televisions, refrigerators, gold coins, mixers, washing machines and DVDs as rewards for more than 3,000 districts nationwide. One loan officer signed up 273 groups in a month. Under training protocols, the ideal number of groups formed per month is 12, the maximum is 36, according to field agents and reports written by Akula.

The result: Management had a great set of numbers to show investors as it shopped the IPO. In a month, SKS could add 400,000 borrowers and 100 branches, and train more than 1,000 new loan officers. SKS had 6.8 million borrowers and had disbursed $3.2 billion in loans. India was pimpled with SKS branches, which bloomed in nearly 100,000 villages.

SKS said it was the fastest growing microfinance company in the world.

But basic principles of lending were overlooked, according to interviews with current and former employees, as well as correspondence and internal PowerPoint presentations by Akula.

Six current and former SKS staffers with experience in the field told the AP they no longer had time to check a borrower’s assets or follow up and make sure a loan was put to productive use. They said that they were pressured to push more debt onto people than they could handle and that the number of days devoted to borrower training was cut in half.

“You have a (borrower group), and a loan officer goes out and trains them, educates them, then they give the loan. That’s the SKS I’d seen in 1999. That was the whole model on which microfinance is supposed to work. In the quest for growth, a lot of these things got neglected,” said Ankur Sarin, director of the SKS trusts, which are the fourth largest shareholder in the company and tasked with looking out for borrower interests.

And once that part of the Microfinance model was shredded, the rest of it fell apart, turning into a vicious circle.

As the relationships between heavily indebted borrowers and loan agents broke down, it became harder to collect.

And so long agents started acting like loan sharks.

One woman drank pesticide and died a day after an SKS loan agent told her to prostitute her daughters to pay off her debt. She had been given 150,000 rupees ($3,000) in loans but only made 600 rupees ($12) a week. Another SKS debt collector told a delinquent borrower to drown herself in a pond if she wanted her loan waived. The next day, she did. She left behind four children.
One agent blocked a woman from bringing her young son, weak with diarrhea, to the hospital, demanding payment first. Other borrowers, who could not get any new loans until she paid, told her that if she wanted to die, they would bring her pesticide. An SKS staff member was there when she drank the poison. She survived. An 18-year-old girl, pressured until she handed over 150 rupees ($3) – meant for a school examination fee – also drank pesticide. She left a suicide note: “Work hard and earn money. Do not take loans.”
In all these cases, the report commissioned by SKS concluded that the company’s staff was either directly or indirectly responsible.

The moral of the story: the market isn’t a Disney fairytale. Companies that get subjected to the full brutal pressure of market forces can easily turn into a horrible perversion of the original social aims. Some lefties might argue that this is the inevitable fate of any attempt to create more humane finance so long as we are living in a capitalist system. I take this as one more example that We Are Not As Smart As We Think We Are and that no matter what kind of economic system we have, our best ideals can be turned into nightmares if we aren’t vigilant – and if we don’t have movements with the power to stomp the crap out of the sociopaths who try to drive us there.

The Banana Peel Institute?

An interesting idea from Alexis Madrigal, via an interview with Grist’s David Roberts:

DR: Your book is about a series of failures, but it shows that there are better and worse failures. Some increase our knowledge, but in some cases, a bunch of work and thought and science just goes poof. How do we fail well in greentech?

AM: The key thing is, we know that most startups are going to fail. The No. 1 policy we could put into place would be to make sure that companies taking government money — on the assumption that it’s a public good they’re doing — have to give up some of their data on how well things worked, how well things didn’t work. Create a library of failure and success. That would be incredibly useful.

Go back and look at all of those ’80s wind companies. Maybe some of them were doing great, and they just collapsed because the leader of the company was a cokehead. We don’t know why a lot of places fail.

This should be a conservative argument: If the American taxpayer going to pay to support the development of these technologies, we want to get the most return on our investment. The key is recording and sharing information. Even though they don’t exist now, there could be structures and policies in place to make that happen.

Two Quotes on Learning, Making Mistakes, and Feedback Loops

As a followup to Monday’s post on We Aren’t As Smart as We Think We Are, 2 quotes:

Fujio Cho, former Chairman of Toyota Motor Corporation:

We place the highest value on actual implementation and taking action. There are many things one doesn’t understand and therefore, we ask them why don’t you just go ahead and take action; try to do something? You realize how little you know and you face your own failures and you simply can correct those failures and redo it again and at the second trial you realize another mistake or another thing you didn’t like so you can redo it once again. So by constant improvement, or, should I say, the improvement based on action, one can rise to the higher level of practice and knowledge.

Danny Meyers, restaurant owner and author of Setting the Table: The Transforming Power of Hospitality in Business:

The road to success is paved with mistakes well handled.

Is "We're Not As Smart As We Think We Are" an Infinite Regress?

A snarky friend asked, how is it possible that We’re Not As Smart As We Think We Are? Isn’t that an infinite regress?

To understand why it isn’t, I’m going to geek out a bit and talk about some lessons a lot of folks – including myself – have learned the hard way about building software:

a) Nonfunctional Prototypes. If I’m managing a project to build a complex piece of software, before the programmers start writing code I often ask them to create a “nonfunctional prototype” – some quick-and-dirty sketches or mockups that the users can react to. Why? Because no matter how well a programmer or I think we understand what users said they want, we almost never get it right the first time – and usually not the second or third or fourth time either. And it’s a hell of a lot cheaper to rip up a quick sketch than to rip up days or weeks or months of coding.

And it’s not just us coders. Someone like Jacob Nielsen, the granddaddy’s of studying “usability,” does the same thing. Why? Because even Nielson isn’t smart enough to know what users want.

Here’s what makes this tricky. When you’re building the first mockups, an awful lot of the time you’re pretty sure you know what users will and won’t like. Even if you’ve been doing this for many years and have been surprised over and over by what users do and don’t find intuitive, some part of your lizard brain thinks you nailed it — or at least a good part of it. And that’s why we have the rule about nonfunctional protos: to put that part of your brain in check.

b) Building Software Iteratively. Rather than trying to build a program all in one swoop, break it into a series of mini projects or “iterations.” Why? Because, as they say in the military, no plan survives first contact with the enemy. It often turns out that users didn’t know what they really wanted – especially if they haven’t used the type of software you’re building. Or halfway through the project, your organization’s needs change. Or you discover that some parts you thought would be straightforward turn out to be a real mess and take three times as long to code. Or after you’ve gotten started, you realize that for a critical facet of the project you’ve been trying to solve the wrong problem. And so on. If you design the whole thing and then build it in one shot, you have to get it exactly right the first time. But if you build it iteratively, each iteration is another chance to respond or recover from the almost inevitable surprises.

When I start a complicated project, one part of my brain knows this. But the other part is whistling, hi ho, hi ho, it’s off to work we go! It’s cheerfully optimistic about how the project will play out. That, ultimately, is why iterations are crucial: they save you from yourself.

And that crazy optimism may be necessary. A developer I know likes to say that new software projects are like giving birth to her second child: if she remembered what it was really like the first time she gave birth, she’d never do it again.

I’ve worked with developers who do remember it all, in vivid detail. These folks don’t tend to get much done. They’re so bogged down by uncertainties and so disillusioned about what’s probably going to happen that they can’t do good work, and they tend to suck the energy out of everybody else.

It takes an insane level of can-do optimism to pull off great software. That’s probably true of a lot of things in life – creating a new company, trying to solve a social problem. That insane optimism is the engine that keeps you running. But you also need a structure that protects you from that optimism, that keeps gently but firmly reminding you, We Aren’t As Smart as We Think We Are.

Values-Based Principle #1: We're Not As Smart As We Think We Are

[Part 4 of Values-based vs. Market-based Approaches to the Economy]

If you’ve ever heard someone preach the joys of a market-based solution, odds are at some point they’ve said, government regulations/bureaucrats can’t be smarter than the market — the economy’s just too complicated. But as we saw last week, creating a market-based solution runs smack into the same problem. In case you need a reminder, here’s one last example:

On India’s Bhilangana river, local farmers run a finely-tuned terraced irrigation system that provides them with rice, wheat, mustard, fruits and vegetables. This ingenious, extremely low-carbon system of agriculture is threatened by a new hydroelectric project designed to help power India’s heavy industry. Villagers may have to leave the valley, losing not only their livelihoods but also their knowledge of a uniquely sustainable modern technology.

Is carbon trading stepping in to support the villagers’ piece of the solution to global warming? On the contrary. It’s supporting the hydropower company, which has hired consultants to argue that their dam will result in fewer carbon emissions than would have been the case if it had not been built. The firm plans to sell the resulting carbon emission rights to polluting companies in Europe. The example is typical of the way carbon markets are undermining positive approaches to climate change everywhere.

I’m guessing that’s not what the designers of carbon emission trading markets had in mind.

So what do we do? There’s a simple solution, used every day in software development (my little corner of the economy), industrial design, and many others: you deal with it head on. You start from the assumption that you can’t possibly figure it all out in advance and you go from there.

If I’m trying to build a complicated database, for example, I start by assuming that I won’t really understand what users want, users may not understand what they want, and what they need tomorrow will be different than today. So, I build software iteratively, so my users and I get to find out for real if we are on the right track. I start with mockups rather than actual code; knowing you probably won’t get it exactly right the first time is a lot less scary when you’re throwing away a paper prototype instead of lots of labor-intensive programming. And I use risk management. I come up with a list of things that might go wrong and what we’ll do to mitigate the risk. Then I watch like a hawk for signs of trouble and move aggressively when I see them.

A lot of the same lessons apply when trying to shove the economy closer towards our values. We start from assuming we won’t get it right and then build tools and systems to help us stay out and get out of trouble.

Take the idea of priming the pump from Auden Schendler’s Getting Green Done. Schendler writes:

government needs examples of how to be environmentally progressive and case studies from which to build policy. Every individual and business matters because we need labs for determining what’s worth pursuing and how best to do it.

So before we know enough to write smart regulations, we can “prime the pump” by funding experiments. That’s how Schendler’s first success at the Aspen Skiing Company happened — he got a grant to fund his pilot project. Later, once we’ve gained enough experience, we can do things like write the first versions of green building codes. But even this will take trial and error to find the right balance.

There are two keys to this approach: holding folks accountable and feedback loops. Instead of assuming that markets will automatically lower emissions, we watch carefully to see if it is actually lowering emissions and then tweak the rules and incentives as we go. Instead of assuming that if Wall Street has plenty of capital and shareholders are happy corporations will automatically create lots of good jobs, we keep a close eye out on what capital is getting used for and whether it’s actually creating good jobs.

It’s not a simple answer. Then again, life isn’t simple. If we start from the principle that we aren’t as smart as we think we are, we are a lot more likely to get to where we want to go.

Up next: placing our bets