I’m going back to the start.
How we got here is important.
Many of us, in our work lives, are driven by victory.
Sales folks, pre-sales, and consulting teams keep count of their wins all the time. We call these targets. They’re linked to incentives — it is how most of the software industry’s compensation is structured.
When we win, we celebrate. We close a deal, sign the paperwork, have a beer and move on to work with that customer and make them truly successful with the technology and services they procure from us.
When we lose, we do a post-mortem. We try to figure out why we lost, and we try to look at it objectively. The idea is not to square blame on any individual, but to build a team that operates like clockwork.
But I’ve always wondered — in the midst of this obsession with numbers and meeting targets — how often do we take a step back and think about why we won? Why is it that we don’t do a post-mortem of a win?
In fact, why do we win? What makes us tick? What are we obsessed with? Why are we good at what we do?
I’ve looked around — and within — for the answer, and many come to mind. A great team. Integrity. Hard work. Dedication. Creativity. Technical superiority.
But honestly, none of these influences wins as much as one thing that is unique to your company.
Something that each of us didn’t have a choice in acquiring, but we did anyway.
Something that was passed on to us.
Something that we cannot unstick easily.
Something that is perhaps the biggest contributor to work culture.
Heritage is important.
To paint a picture as to how significant what we inherit is, here are three real-world sales-wins that we sliced and diced with the power of hindsight, to examine exactly what made us win.
2017. An insurance firm in Bangalore.
“Cheers”, says our new hire sales guy — let’s call him John Doe — as he sips on locally brewed hand-crafted beer in a microbrewery in central Bangalore that would make its ancestors in Michigan proud.
John Doe isn’t just a sales guy, but seasoned professional with over two decades of experience selling everything from boxes to cloud applications. It’s been a good evening. We’ve just been awarded a contract to digitally transform how our customer — an insurance firm based out of Bangalore — on-boards their customers.
The possibilities are endless, from automating underwriting, to customizable workflows, to making decisions in real-time. All of this wrapped with an intuitive user experience that does not burn a hole in their pockets to operate or run. The solution is a true best-of-breed, a combination of TIBCO’s classic integration platform, with Red Hat’s business rules and workflow engine powering the backends. Slapped on these services is a layer of Angular that makes a lightweight user experience possible. We’re very proud of the architecture and are excited to start the project.
2018. A bank in Mumbai.
It is the middle of the week on a wet evening in the offices of a large financial services institution. Mumbai. John Doe’s just done wrapping up the paperwork. We are going to help a large bank in the country automate thousands of their escrow deals.
The Real-estate Regulation and Development Act, or RERA as it has come to be known, is a set of laws that helps protect home-buyers. It was passed in the House of the People (Lok Sabha) in India on the 15th of March, 2016 and came into effect on the 1st of May the same year. RERA introduce many reforms, one in particular requiring property builders to open a separate account for each project they are developing. The property developer has to deposit 70% of the money raised for the project in this account, and these funds can only be used to develop the project.
With RERA in place, the number of deals/contracts that banks entered into, with the builders, and the structure of these contracts — very similar to an escrow arrangement — meant that their operations teams had to man up.
All of the aforementioned bank’s work is currently on excel and e-mail, and without a good system in place, their ability to grow the business and scale the operations, and run it all smoothly and risk-free, is hampered. They looked at our product and it solves most, if not all, of their problems. It’s a straight-fit and after a tough round of negotiations — they are a bank, after all — we’ve closed the deal.
2019. A financial services institution in Ho Chi Minh City, Vietnam.
A financial services company that offers employee benefits programs to its customers, targeting the rural workforce in the country, is looking at replacing their legacy technology. At the heart of this transformation program — quite literally — is the integration layer that stitches all the front-end applications (channels/customer-experience components) with the back-end systems (loan processing/payments/customer-servicing components). There’s an RFP out for which we’ve placed a bid. Our top solution architect has already visited HCMC, Vietnam, where he’s presented our architecture, approach and credentials.
Commercial negotiations are up next, a week later, in Vietnam again. Yours truly has just flown into the country, and Grabbed (the Uber of South East Asia) his way to a 13ft x 12ft conference room, surrounded by six representatives from the customer, mostly C-level execs and their direct reports. The possibility of a win (or loss), and a projector projecting my slides, hangs over my head.
In less than an hour, we have shaken hands. The negotiations were hard, but fair. There was no discussion on the technology components; it was purely commercials. I am, admittedly, not the best negotiator in the company, and the only reason I am in the city is that we forecasted — wrongly — that we would be discussing the design and architectural components.
We won all these deals. Except that, in hindsight, we had no business winning either of them.
We’re an integration company. We don’t build applications. We had no insurance expertise. Some companies live and die by building workflows to onboard insurance customers. We aren’t one of them.
We’re a data management company. Some companies live and die by building workflows to manage payments. We aren’t one of them.
We’re a company headquartered in Palo Alto with most of our business — both revenues and headcount — in India. We have no presence in Vietnam whatsoever. No one in our team speaks the local language. We can barely hand-motion our way from the airport to the hotel. We have zero understanding of the local customs. Surely, there are software companies in Vietnam that do exactly what we do?
So why did we win these deals? In all three situations, the prospect-turned-customers-turned-champions liked a few things about us.
We were honest. We didn't lie during the pre-sales cycle. We didn’t have to; our work and the technology speaks for itself. But that wasn’t why we won.
We worked our asses off. They could see the effort we put into our proposals, both technical and commercial, and they knew we had thought through every scenario, requirement and the approach in detail. But that wasn’t why we won.
Were we priced the lowest? No, we quite likely weren’t. We were, at least, 15% above most of the lowest bids.
These wins — and many other wins — boiled down to one important thing that we had, which subconsciously found its way into everything we did. Our heritage.
Our heritage is being real-time. Everything we do, from APIs to micro services, from data management to data integration, from escrow operations to building a partner ecosystem, is built on the bedrock of what we inherited from our past lives, which is to make data real-time.
Nearly every design decision we make, pre-sales and post-sales, revolves around making data real-time, whether it is about stitching systems together or distributing data through a kafka broker.
Nearly everything we code is wrapped in an easy-to-consume API, making it easy to integrate. The acronym “API”, to many, is a buzzword. To us, it is bread and butter. Building APIs is in our DNA, most of us are just coming to terms with this reality.
In all three of these deals, the customers went with us because we knew how to manage and integrate their data better than anyone else they had spoken to. It reflected in our architecture, our presentations, our proposal — heck, even in our contracts. They could see — better than we could — that we were the best at this.
And that’s why we won.
The heritage at CAPIOT and appveen comes from decades of experience working with APIs before the acronym got sexy. You can trace this DNA to two very different sources.
The TIBCO DNA
The first is a clear bloodline from the past-employer where many of us, including the core founding team, spent years at: TIBCO. Back in the late 90s when the dot com bubble was about to burst, one Silicon Valley company was focusing on solving a very important problem: data integration. TIBCO (short for The Information Bus Company) helped pioneer the enterprise service bus in the early days of data integration, and it was well ahead of its time. Its founder, Vivek Ranadivé, had a brilliant idea. From that IITian-turned-MITian brain, the notion of an information bus, where applications could just plug in and out of it and exchange information, was born.
I worked at TIBCO for eight wonderful years that ended abruptly simply because I had to give a shot at starting up, and all of my co-founders would agree that this was the only thing that could’ve gotten them out of TIBCO. We were quite likely to retire there.
At the helm of TIBCO, Vivek was no random schmuck, and his story is somewhat documented in Malcolm Gladwell’s David and Goliath. To put it into context, he managed to convince the heavy hitters on Wall Street to digitize their trading platforms using his technology, and he won against all odds. This cleary pissed a few of the biggies, who abbreviated TIBCO as “That Indian Bastard’s Company”. Vivek did the smart thing of surrounding himself with brilliant people and built a company worth being loyal to. He and his direct reports ultimately created what we called the TIBCO DNA.
The TIBCO DNA is a set of beliefs and practices that define how many of us do our day to day jobs in the world of distributed software computing. It has been passed on for over two decades, and remains at the core of many other companies that are being run by people who worked at TIBCO in their past lives. The TIBCO DNA isn’t easy to find — a google search brings up only 94 vague results at the time of writing this post — but it is quite prominent in many of the top tech firms today. From Red Hat to Mulesoft, from MongoDB to Solace and Elastic, you will find this DNA spread all around the people that make these companies tick.
The TIBCO DNA means different things to different people. Its origins are unknown, or lost as an undocumented memory. What inspired it, is something we may not find out. It has elements of entrepreneurship, pragmatism and integrity.
But above all, it focuses on keeping data real-time, and getting intelligence out of it. TIBCO’s obsession with speed and analytics is evident; they have a very well-documented partnership with the Mercedes Formula 1 team, and you only need to look at Lewis Hamilton’s or Valteri Bottas’ helmet for their logo at the chin.
We’ve inherited this DNA in our lives. Our first hire was a brilliant TIBCO architect. Few have influenced our people as much as he has. Over half of CAPIOT has worked on TIBCO products, and has diversified into parallel technologies — Mulesoft, Red Hat, Apache Camel, the works. This half of CAPIOT has an unfair advantage in comparison to our competitors; they have done nothing but integration and APIs day-in day-out. They’re the best at it.
The automation DNA
As great as TIBCO was, it remained proprietary technology for a very long time. In 2006, I met two of the brightest technologists I have ever worked with and simply put, I am super-proud just to have them as friends. They were good coders — maybe even great — but it went further than that.
They built a culture of automation. They built a culture of exploration. And they built a culture of consuming open-source technology simply because:
- It was good
- It was easy, and
- It was out there
When we started up, these two guys were my early hires. It was a no-brainer; they were swiss-knives. Give them a tool and they would excel at it in no-time. But more than anything else, they focused on automation.
If it took them two minutes to file their expenses, they would spend days automating it. But they never had to do expenses again.
They went about automating everything, from slackbots to troll executives to CRUD operations. Ultimately, they helped build one of the most sophisticated data management platforms that is only getting started in terms of market adoption. Nobody does CRUD + APIs as well as we do. We’ve built over half a million in subscription revenue on the backbone of these frameworks, and we wouldn’t have gotten here if our team had gotten behind our obsession to automate the journey of managing data.
In the five years since we started up, we have looked at all our successes and failures, both critically and nostalgically. We are very proud of what we have achieved; the team we built, the customers we’ve acquired, and the work we’ve done for them. But it is only recently that we started recognizing the power of our heritage.
What got us here may not take us ahead. We most likely will have to re-invent ourselves as the world changes. But knowing what is at the core, being able to adapt to variations of that, and staying true to our real strengths while being honest about our weaknesses, is what will help us embrace the future for what it is.
The author is a nerd who dabbles in code, slides and spreadsheets for the daily bread. Almost the entirety of the rest his time is spent in watching, talking about and thinking of football and Formula 1 while attempting to survive as nomadically as life permits him.
