Part 1- The Most Powerful Entity on Earth is Not a Tech Company, covered how we found the right people and got banks to lend. But finding people and giving them money isn't enough. We need to train them to utilize the money effectively for setting up a business. This is where human behavioural design comes in.
Let me tell you how government programs normally work. A well-meaning rule is framed and executed. People figure out how to game the rule. The program starts focussing on the game instead of the goal. When we were designing the training program for Mission YUVA applicants, we knew this was a problem to be solved for. So we decided that we are not going to fight human nature but rather we would design around it.
Governments normally reward inputs rather than outcomes. They do this because inputs are usually easier to measure. But we decided that the script has to be reversed and we decided to tie all monetary incentives provided by the government to the outcomes that are achieved. We decided that the subsidy would not be given to the Mission YUVA applicant - because she/he got a loan sanctioned.
Instead the government would give subsidies only when applicants complete training and when they submit a completion report within one year of credit disbursal. Training ensures that applicants would be able to utilize the credit amount effectively and completion report ensures that the applicant has set up their business successfully.
The government is not in the business of funding credit applications. It is in the business of creating entrepreneurs. The incentive structure now reflects that goal: not the bureaucratic shortcut that looked like the goal.
Key Learning 1: Always reward outcomes, not inputs.
The same logic applied to training itself. Even though we have made training mandatory, we were worried about the effectiveness of the training program. Are they actually happening on ground? Are applicants learning from the training programs? If we don’t check for this, the training would become a beautifully documented fiction. So we created a 6 layer check for ensuring that applicants show up for the training program and they learn something.
1. Geo-tagged attendance with photographs: Every trainee’s attendance is recorded with a photograph, a timestamp, and GPS coordinates. Not the training centre’s coordinates. The trainee’s. So they actually have to show up.
2. Independent attendance verification: Attendance records and photographs are cross-checked by a separate team at the district level. The training centre cannot verify itself.
3. End-of-program tests: At the end of every batch, all trainees take a test. Not to fail them. To check if they have learnt something.
4. Random field visits: District officials show up unannounced at training centres. No prior notice. No time to prepare.
5. Post-training phone call verification: After training ends, a sample of trainees are called. Did you attend? What did you learn? Training centres that aren’t working show up here.
6. Data anomaly detection: We track KPIs across every batch, every district: batch sizes, completion rates, test scores. Any number that falls outside a permissible range gets flagged and investigated.
There are six Swiss cheese verification layers to check training effectiveness, not because we assume everyone is dishonest, but because any system with a reward will be gamed by someone. If we don’t catch it early, the problem will spread quickly.
Key Learning 2: Trust. But always verify.
One day, going through training completion data, something stood out. A single trainer in one batch had trained fifty trainees with a 100% completion rate. This sounds wonderful at the surface level.
But here is what the data also said. The average batch size and completion rate in that district was 24 and around 50% respectively. So we have one trainer with two KPI’s as outliers. When something sounds too good to be true, it usually is not true. We spoke with the trainer and had a conversation so that the same pattern should not appear again.
Key Learning 3: You don’t need to catch every data anomaly. You need to make it clear that the system is watching.
Now for the other side of this story. Because all of this verification exists for exactly one reason: to make sure the businesses that get set up actually thrive. And one field visit reminded me why that matters.
We walked into a training centre expecting the usual. Half-empty room. Trainer reading from a slide. Trainees on their phones. Instead, we found a young woman in the front row with her notebook open and her hand raised. She was asking the trainer how to prepare a DPR - Detailed Project Report, the document a bank needs before they’ll even consider your loan application. The trainer was explaining it carefully, going back and forth with her, making sure she understood it. Nobody was performing for us. They didn’t even know we were there.
That 23-year-old will probably submit a DPR in the next few months. She will probably get a loan. She will probably start something. And she will probably be very good at it as she is already asking the right questions before she has even started.
You cannot build a system that assumes everyone will do the right thing. That’s not pessimism. That’s engineering. Bridges are not designed assuming no one will ever drive a truck over them. But you also cannot build a system that treats everyone like a suspect. The woman in Samba doesn’t need geo-tagging and phone verification to prove she is learning. She is learning because she wants to.
Key Learning 4: Build systems that make the right behaviour the easiest behaviour.
1. Always reward outcomes, not inputs: Measuring inputs is easier, which is exactly why it’s dangerous. A program that counts loan sanctions instead of businesses started will produce a lot of loan disbursals and very few successful businesses running on ground. Whatever you measure is what gets managed. So measure the thing that matters and reward that behaviour.
2. Trust. But always verify: People will always take the path with the least resistance. A system with a reward will encourage them to get the reward without doing the work. Six layers of checks is not distrust. It’s how you protect the people who are doing it right from being undercut by the people who aren’t.
3. You don’t need to catch every data anomaly. Make sure that the system is watching: People don’t game systems when they believe that the system is paying attention. What you do when you catch an anomaly matters more than the detection.
4. Build systems that make the right behaviour the easiest behaviour: The program exists for learners. The verification exists to protect them. The moment the checks become so overwhelming to the point that people struggle to learn, you’ve lost the plot.
