— Lessons from winding down a FinTech startup
Sometime in the middle of 2019 we decided to wind down our startup Artoo. I take the liberty to say ‘our’. I am not one of the founders. I was a fairly early employee. I am writing about my experiences and lessons learnt along the way.
So what did we do, at Artoo?
No, not only that. Love the vibes in this one though. This is what we really did.
Allow me to zoom out a bit.
Lending in India has a ‘missing middle’ problem. On one hand, there is micro finance. Born of the socio-economic genius of Mohammad Younus, it’s based on the premise of leveraging social ties for establishing good borrowing behaviour. How can you lend to a poor person with no assets, sporadic income if any and no credit history whatsoever? You cant. But what you can do is lend small amounts to a group of such people and make them collectively liable to repay the loan. The strong social ties that led to unregulated and informal borrowing, now leads to formal finance.
Lending in very small amounts to groups or individuals, or rather, micro finance is now well established. Lending to large organisations was always well established. What remains is the Missing Middle. Small enterprises; your flower seller, mechanic, small parts manufacturer or beauty salon.
At Artoo, Sameer Segal, Kavita Nehemiah and Indus Chadda saw an opportunity to solve this challenging and highly impactful problem with technology. How can technology help improve processes, manage risk and help make intelligent decisions when lending to highly volatile businesses with irregular income, spotty credit history and cash heavy transactions.
Artoo was founded with the vision of technology enabling financial inclusion. Taking technology to people who need it most.
Our clients were micro finance institutions and small finance banks lending to micro enterprises. Our product helped the agents and employees of these institutions in loan origination, credit underwriting and decisioning. Faster and with high accuracy. We attempted to solve the problem of micro-enterprise credit with ‘high touch and high tech’ . The loan agent is not eliminated due to technology but empowered.
I spent several years working in large organisations before joining Artoo. The biggest shift was in the intensity and variety of the experience. Stuff that happened around me in a day—leadership team meeting, design discussion, code-random interruption-code, surprise announcements, what lunch to order, laughs at inside joke, client escalation, code review session, chai is here, fight over something, prod issue — than I was used to happening in months! All under one roof and in one big room.
I loved every bit of it. We had good engineers on board. Some really great ones in fact. At one point we counted some of the top MFIs and SFBs in India as our clients. So what went wrong? I don’t want to presume I know. With all due respect to similar literature out there, I feel ‘if only we had done that’ is hypothetical thinking.
I’d like to talk about my learnings instead. I am an engineer. Most points here might be from a technical perspective. Here they are in no particular order
Are you tunnelling? Be aware
Have you experienced having only one thought in your mind? What was the longest it lasted? Sometimes our single minded focus on a task, project or idea can become an all consuming obsession. Without us realising it. We work on it day and night. Thats all we can think of and talk about. All our interactions with people are in the context of the object in question. Isn’t that good? I suppose yes.
Healthy obsessions have broken sports records, created breathtaking art, led to scientific breakthroughs and generally advanced humanity.
I have learnt the hard way that there is a cost associated. The distinguishing factor of startups lies in ideas that solve palpable problems. They naturally tend to consume us, leaving no room for any long term or high level thinking, causing what is aptly called tunnelling. Not only do we have a single minded focus, we have no place in our minds for anything else.
I have lost count of the number of times I tunnelled on a problem at Artoo.
Every hour, day, week or month spent tunnelling on a problem is time and mental leisure lost for new ideas, experimentation, planning or rejuvenation. More practically, you might miss an exciting new client, a great potential hire or that house close to office
Does it make sense to consume your mind and energies with that one object indefinitely? Can you time box yourself? Maybe a rhythmic approach works. Where you focus and de-focus in alternating periods. Or is it possible to focus and also have mental space for other thinking? I don’t know. My learning is to be aware of the extent to which you are tunnelling. As long as you are aware, you are in control.
What problem are you solving?
As engineers, we strive to build highly reliable, available, scalable and secure systems. We want to use cutting edge tools and frameworks as and when appropriate. We want to write minimal, clean and efficient code. We spend hours learning, experimenting and brainstorming on how to build such software.
Before we know it, the systems we build become an end in themselves and not a means.
Hmmmm…. we need to do that? Framework X doesn’t allow it. Will take a lot of time to come up with a workaround. Can we do something else instead? We have a ABC architecture. Therefore, this particular requirement will be solved this way and will require so much time. We should push back on this particular change. Too many changes across systems required for a minor enhancement.
We took decisions like these day in and day out. In retrospect, we put our systems and ahead of our clients without realising it.
There is always a tussle between the problem space and the systems built to solve it. Like all systems, software increases in entropy as it matures and unless we make an effort, can start dictating the problem instead of the solution
The key again, I guess, is awareness. We need to be aware of how the increasing complexity and chaos of software we build impacts the problem it’s trying to solve. That would lead to adoption of DDD which I will talk about next.
Development should be domain driven
I suppose I was nodding my head all along as I read Domain Driven Design by Eric Evans. What particularly struck me is how DDD can help open up new opportunities for software at a stage where it tends to become legacy. In DDD the problem domain is expressed and solidified by the code, design artefacts and the very language the team speaks among themselves and all stakeholders.
This leads to a model of the domain that is collectively expressed and enriched by domain experts and developers alike.
We tend to think that the software we build is the primary artefact of the development effort. With domain driven design and thinking you realise that it’s not so. The most important artefact that is collaboratively and iteratively pruned, honed and developed is the domain model
Whats interesting is the impact this rich domain model has, as software matures. Instead of increasingly unwieldy and brittle software that becomes a candidate for re-architecture, we have one that provides insights into the domain and easily lends itself to changes.
If there is any regret I feel, it’s not incorporating DDD. Given the complex and pristine domain of Artoo the insights from DDD would have been truly exciting.
For SaaS, think of product and service boundaries
What is a software product and what is a service? In rudimentary terms a service is tailored to solve a problem in a specific context. As a service, a solution might be developed for retail firm ABC to manage inventory or to track fleet for transport company XYZ. A product attempts to solve the same problem in a context free way. A fleet tracking system is developed such that any transport company can use it with a subscription plan. In other words, its SaaS — software(product) as a service. The advantages are obvious.
The solution developed is generic. A new feature or enhancement does not have to be added to all custom solutions. Experience of use cases across multiple client contexts leads to new domain and product insights. Most importantly, the aggregation of data can lead to intelligent system behaviour.
It’s not surprising that a lot of entrepreneurial energy is currently concentrated in developing SaaS solutions. But they raise significant concerns. How to handle custom behaviour that might be critical to a particular use case, but not others? Is every client request a product feature to be supported? Such customisations would be expected in the plain service model.
The success of the SaaS model depends on how the interplay of product and service is handled
There are no standard solutions to this problem. Intuitively, the product should be customisable through configurations. We followed that intuition at Artoo. But the more configurable a product is, the more complex the configurations themselves become. So much so, that handling the configurations of a product starts becoming a specialised skill in itself. After a certain point we did get overwhelmed with this complexity. What helps is to actively think about what is the product is and what it isn’t.
While a custom solution for each client may not be scalable, every scenario and use case baked into the product is not sustainable either. Be prepared to have customisation layers built as the product usage matures with clients.
Have humility while hiring
Software engineering is not a standardised field.
What is the metric of good software? How many requests are served in a second? How fast the web page loads? How much time it takes to develop? Or its lifetime? Is long lived software good software? With all due respect, I think we don’t know. As a corollary, we also don’t know how to assess and hire engineers
We need to first recognise assessment and evaluation of engineers as a problem in its own right. In fact, an as yet unsolved problem in software engineering.
What do we look for in software engineers? At best we have some heuristics. Algorithmic problem solving skills. Level of knowledge and skill in various programming languages and frameworks. Ability to grasp new technology quickly. Software design ideas and approaches. Great communication skills.
Assessing a combination of these in some proportion might work well enough. But then it might not. We need to decide, based on organisational context, what works best and continuously refine it. Interviewers should be trained accordingly. Good engineers do not automatically make good interviewers.
Assessment and evaluation of software engineers is a hard problem. If we can acknowledge as much, the humility will follow.
It’s all about the people
It is. My biggest gain has been the friends I made at Artoo and what they have taught me. It is the kind of learning that could not have come any other way.
You know a great experience when it transforms you. I am wiser now than when I started. I am proud to say I have lived and learnt.
