Delhi Aur Developer Dur Hai
On bridging the divide between public policy, technology and ground realities and describing my dream gov-tech job role.
Delhi Aur Developer Dur Ast Axiom (Delhi & Developer Are Still Far)
The greater the physical separation between the policy-maker, developer and end-user, the greater the divergence between policy objectives, IT solutioning, and ground-reality.Nizamuddin Auliya, Probably.
Quite simply, if your developer or decision maker sits in New Delhi and the end-user sits in the Gram Panchayat office in District Dumka, there is a higher chance that what is being developed is cut-off from ground-reality due to difficult feedback loops in all directions.
The week before, a high-level joint team of senior NIC and Data & Insights Unit (our team) visited two different states to examine the complaints we had been hearing about one of our key IT systems.
While I've been avoiding travelling outside of Delhi for work (the “field”) over the last two years, this 6-day trip ended up being my most cherished work-trips. The fact I was sick the entire week after I returned and had myself googling early onset of knee issues doesn’t dampen one bit the prior week.
The week started with us being in a make-shift conference room packed with District and Block officials in the Trivandrum office of society incharge of social audits in Kerala and ended with an immersive meeting in Pipili Block Office in Odisha where the senior-most technocrat in-charge of our government program sat next to the Data Entry Operator for more than an hour as the operator navigated the IT system and tried to complete their tasks, stopping to show the issues they were facing etc. To emphasize the beauty of this moment and personal cherish, this exact frame for which I have no photos, is one of the top highlights of my career with the Ministry of Rural Development.
After the meeting, as the rest went to the airport on their way to Delhi, Richa and I sat on the stairs of the beautiful Shanti Stupa in Dhauligiri trying to reflect upon the week we’ve had. We had booked an extra day in case we needed to do more fact-finding, but we both were satisfied with what had already been seen and discussed across the weeks. There wasn’t any need for convincing or additional facts.
While we were reflecting about the trip, we both were convinced how significant this trip was. This was important work - work that needed to be done more often. There was a reason I limited going to the field once I moved from PMGSY to the Data & Insights Unit (DIU). The DIU is set up within the IT Division of the Ministry of Rural Development, so while it can work across all schemes (DDUGKY, PMGSY, NREGA etc), it isn’t placed within any programme division (with a scheme) thereby limiting the operational change it can affect. You are away from the daily operations, so while it allows for more strategic distant work, you are cut-away from being in the thick of it and solving immediate problems. When I was in PMGSY, if I was on the field and saw some issue related to the MIS or operations, I could simply call the head developer, or go back and attempt to fix it with the relevant team without the necessary baggage of presentations, approvals, follow-ups. I was an insider. That’s not true to the same extent for the DIU and while that is by-design, it is still to my-annoyance. The few visits I did to the ground as part of DIU, I soon realized I was uncomfortable talking to functionaries about the particular niche problem statement we could solve and not be able to do anything about the issues they had prepared already about their day to day.
This trip was different though. The head technocrats in-charge of the IT systems were travelling with us and were explicitly here to listen to issues and find solutions. Our role was meticulous note-taking, facilitating and translating between the end-users and the technocrats such that neither side is misheard. It was an extremely positive and inspiring trip to see the conversations unfold. All of us were aligned that we were here just to listen. We weren’t thinking about how we’ll go back and convince or re-create the bugs, the decisions were being taken right there and then by the technical heads. It was beautiful. It was enough to warm up slightly a jaded heart which had decided to strategically remain in bliss ignorance.
Technically such trips should happen more often, but the senior technocrats visiting probably couldn’t spare a week like this often as all other work that depended on them back in Delhi halted as also seen by how often their phone rang. And while the intermediate is to atleast ask senior developers, if not heads, to visit states/districts once a month to remain empathetic, our minds wandered to a dedicated role just designed for this.
Enter, the Travelling Product Manager. To me teammates, it is no secret that PM’s are my favourite roles in the government but this one is slightly different.
The Travelling Product Manager is a sub-category or niche of the PM role.
Given the Delhi Aur Developer Dur Ast Axiom reiterated below:
The greater the physical separation between the developer, policy-maker, and end-user, the greater the divergence between policy objectives, IT solutioning, and ground-reality.
The task then of the Travelling Product Manager Problem is as follows: Given an IT product, and the distances between end-users, developers and decision makers, what is the shortest number of trips between each party, that the product manager has to do to bridge the divide between parties and get the least compromised product improvements approved. Rated NP Hard or Notoriously Problematically Hard.
Instead of explaining the whole idea, I’ll just write down the hypothetical job post below:
Title: Travelling Product Manager
Reporting: Joint Secretary (scheme in-charge)
Office: With the technical team and developers.
Responsibilities:
75% of the time will be spent to travel to various parts of the country and spend time with Users of the MIS /Apps including Data Entry Operators, Panchayat Secretaries, District and State Information Officers.
Conduct Training Workshops at various levels explaining different modules in the MIS and their intended uses.
Identifying MIS/App related problems faced by different functionaries on the ground not limited to lack of modules to do certain tasks but also how difficult it is to conduct certain tasks.
For any issue identified, the TPM will on the fly create detailed Product Requirement Documents (PRD) within the existing framework of the MIS and submit them for development on returning to New Delhi.
While e-ticketing systems exist, the TPM will target going to most lagging behind GPs/Blocks/District and trouble-shoot problems instantly either themselves or by being on call with senior developers in Delhi. While solving issues on the ground in the micro, this also helps in consolidating and framing larger issues to be solved when you return back to Delhi.
TPM will not limit the technical issues but also bring back the operational and administrative difficulties on the ground which limit the implementation of the technical solutions being rolled out.
Minimum Qualification Requirements:
Technical Background (has coded) or has product managed technical teams closely.
Understanding of Policy/Administration functioning on the ground.
Deep empathy plus reading between the lines (of code, of policy and literal spoken languages)
Mission Driven & Solution Oriented
Can convert findings on the ground into Product Requirement Documents & Figma Mockups
Fancy Powerpoints & Report Writing
Notes:
Technical background important? Unfortunately, without a technical background it is difficult to win legitimacy from the existing technical teams and thereby limiting your ability to get action on the findings. Submitting a report is not enough, they need to write a PRD or make figma mockups to solve for the problem identified. They’ll need to sit with the technical team, test the requirements if needed and be easily accessible in case the developer has a doubt.
Our objective here is not to identify issues but to also be part of the conversation where their solutions are discussed or even when new modules are being designed. Someone who has a technical background (web/app development) or understanding of how gov-tech architectures operate will be able to better string together isolated issues into architectural issues or be able to parlay with technical teams when presenting these findings. If you are completely non-technical, you’ll have to take whatever explanation the developers will give you when you present your findings. I’ve been on both the receiving and dealing end of “technical explanations” and I can assure you a good percentage of them are meant to diffuse the situation and not truthfully explain the situation.
Why sit with technical teams and not policy teams? The role is not to find flaws in the technical team’s work, but to co-fix things and reduce the information symmetry between the developers and the ground realities and policy objectives. Also by being situated with the technical teams, they’ll have a better understanding of the system architecture and better contextualise the problems they see on the ground.
Reiterating, TPM’s personal OKR is in getting things fixed, not pointing out issues.
If being within the technical side of things is so important, why report to the administrative head or policy maker? There has to be a chinese wall between the person who writes the code and the person whose insights may actually increase the amount of code that will need to be written. While the TPM needs to have a foot in both the policy and technical sides, they need to lean slightly on the policy side of things as technology is in service of the policy objectives and it is important for the TPM to remain grounded in that.
Public Administration/Policy Experience? A lot of technical issues are administrative issues and vice-versa. You should be able to identify that the lack of take up of an app on the ground is linked to the lower administrative caps on travel related spending currently provisioned to frontline engineers in the state budget. As you report to the administrative head of the program, such insights from the ground will be extremely valuable.
If any donor agency is reading this, here is your cue to create a fellowship for just Travelling Product Managers in the Government - we’ve had enough of generic project management type fellowships. In an alternative life, where my duties could be limited to just this, I would take this job in a blink of an eye.
Submitted Please.