‘They’ve Stood By Us From the Beginning’: 7 Years of Fruitful Work with a Remote Development Team

Tips for long-term cooperation with offshore teams from Mike Manning, founder of DealVector

DealVector is a provider of the first secure electronic communication network for the fixed income and structured credit space. The company enables investors to connect with other bondholders, improving transparency, building liquidity and protecting bondholder rights.

As a big outsourcing fan, Mike Manning, Co-Founder & CEO of DealVector, stands for long-term cooperation with remote development teams. He believes that the overall performance of the project depends on the people you work with. If you manage to find the right team and lead them towards success, working with them 7 years in a row won’t seem to be a challenge.

In his interview with YouTeam Co-founder Yurij Riphyak, Mike shares his recipe on project success — from the idea to implementation stage. If you want your remote team to build a product of value, keep reading!

Yurij: Can you go a little bit back to the past and remember how the idea for DealVector emerged? What were the first steps? How did you start getting momentum with this project?

Mike: My co-founder had the vision of DealVector banging around his head for a couple of years.

DealVector is the first global fixed income asset registry and communication platform to allow the beneficial owners of specific bonds as well as anybody else affiliated with those bonds – the issuer, the trustee, whoever – to reach out and speak directly to each other.

Yurij: Fixed income assets are mostly bonds, right?

Mike: Yes, asset-backed securities in particular. These were the things that blew up the world during the Global Financial Crisis, and the inability of investors to communicate was a significant exacerbating factor. This is because investors possess certain rights that can’t be exercised individually, but only in concert with other investors.

In the case of the RMBS market, the epicenter of the crisis, investors bought bonds backed by poor quality residential mortgages. As these mortgages defaulted, it became clear that they were in breach of the underwriting guidelines (or quality standards) that had been promised. Investors were protected against exactly this issue by the originator’s representations and warranties. They had the right to lodge a “putback claim” and demand the loan be bought back at par-effectively a money-back guarantee for a defective product.

There is a catch, however. A putback requires 25% of the investors in order to lodge the claim, and this is where the absence of bondholder communications became such a problem. If investors are unable to find one another, they are unable to reach the 25% threshold. Rights that exist on paper don’t exist in practice.

The reason it is so hard for investors to find one another is that there is no central registry of beneficial owners anywhere on earth.

This is a side effect of the creation of the Depository Trust & Clearing Corporation (DTCC) in the 1970s.  DTCC became the central registry of ownership information, but only records the custodians (or “Street Name holders”) of the assets. The custodians maintain individual registries of beneficial ownership for their clients, but as there are over 900 custodians the information is highly fragmented and inaccessible.  

While this greatly facilitated trade settlement, it resulted in a tremendously opaque ownership record. This is the problem DealVector set out to solve.

Yurij: In my understanding, DealVector traces each security all the way up to the actual beneficiary. Is that right? How does this work for me as a customer? What would be my experience?

Mike: The customer experience will be a kind of LinkedIn for bond owners. You join DealVector, upload a list of bonds that you hold, and receive a numeric ID that cloaks your identity.

You can then reach out to other bondholders. You do this by addressing messages specifying two “vectors” of approach: the bond and the type of person you want to talk to – investor, broker, dealer, trustee, etc.

We are leveraging user-generated content to rebuild the central ownership registry that was lost with the creation of DTCC.

Yurij: I assume the identity of the parties remains hidden during the process. Let’s say, you’re talking with the number. You don’t see the actual person’s profile, right?

Mike: Not until you want to. You have to have what we call “controlled transparency.” You have to make transparency work for this particular market where people simultaneously want transparency and secrecy.

They want transparency for everybody else but not for them. We mediated that through the numeric IDs, augmented by authentication levels built on top of that.

Basically, these levels include:

1. Role validation. Proof that you work for the person or the company that you said you were working for. You could be a lawyer, a trustee, anybody in the market – but you have to prove professional affiliation with the firm consistent with your registered role.
2. Docs verification. Proof that you not only work in the validated role, but that you are affiliated in that capacity with the specific bond referenced in the message. You prove this by showing DealVector documentation to this effect. DealVector witnesses this and marks you as “Docs Verified”.
3. Contact escrow. Once you wish to move beyond the numeric IDs, you can execute the contact escrow feature, which allows both parties to agree to mutually release their true contact information and continue the dialogue offline.

Yurij: It’s interesting – what were your first steps?

Mike: We did two things they say you cannot do when starting a company.

1. We started the company without a technical co-founder. I’d never started a company before, nor written a line of code, nor had Dave Jefferds, my co-founder. Conventional wisdom is that you need a technical co-founder or you are doomed to fail. There is a good reason for this conventional wisdom, but we were able to compensate it by finding really smart engineers who offered invaluable coaching.

2. We built the first generation product offshore. This is something else that is supposedly impossible, but we managed to find a fantastic development partner in Talentica Software.

We experienced none of the classic problems people cite about offshore development, such as poor communication or an unwillingness of offshore engineers to actively collaborate and contribute to improving the end product.

We built and launched the entire site with no US-based engineering, and have continued to operate the site with high levels of uptime ever since.

Yurij: So how did you build a proof-of-concept level of product, just by yourself?

Mike: 1. I didn’t know anything about how to build products and had no technical background. But I was a whiz with Excel — the duck tape of the business world. You can do anything with Excel, even build a fully functioning wireframe of a website.

Not being familiar with any of the wireframing tools out there, this is what I did. And it proved more effective than writing requirements documents. I could demo the wireframe to clients to get feedback. Providing a working model to the engineers gave them a much better feel for how the product was supposed to perform.

2. I also found an engineering mentor – my brother’s co-founder at the company they started. He gave me fantastic advice and also connected me to potential development companies.

3. We interviewed a bunch of different people, from single individual developers in Ukraine to established firms.

4. After numerous discussions, we selected Talentica, an Indian development firm whom I could not recommend more highly. 

At first, we considered doing something very quick and dirty in Drupal in order to get an MVP up and running. But developing offshore was so much less expensive that we were able to afford a much more sophisticated build–one that did not need to be re-written after the initial POC stage.

Yurij: So you could afford to build a more full-fledged version of a product, right?

Mike: Yes, that was the difference. I learned a lot as a non-technical person. Also, the firm that we hired gave us really good people. They don’t have a stable of engineers they allocate to various projects. Instead, they find out what your architecture is, what language you’re coding in – and they hire people specifically for you.

Yurij: Do they have a management layer?

Mike: Yes, we had an overall account manager, a lead engineer, and the team underneath him. We also had contact with the company founders.

Yurij: You don’t talk to developers, do you?

Mike: We had a call with the entire team twice a week, so I was talking directly with the engineers.

Yurij: And they were dedicated to your project, right?

Mike: Yes. The team grew over time, but the original two engineers — Piyush and Subhrojit — are still with us 7 years later.

Yurij: OK, there are three most common worries for people who don’t want to go with remote development. First is the risk of losing control over the IP, in different ways. Second is the time zone thing. And the third is like all types of cultural things, starting from the language and ending with the management practices. So can you like briefly address all three?

Mike: I can tell you what my experience was, but I was lucky in the caliber of people that I’ve got. I think that we mitigated these problems in three ways.

The first thing is obvious – everything is committed to GitHub, so you’ve got the code itself.

Second – my technical advisor Samir knew the team very well. They were not just a couple of guys all on their own, and Samir had a lot of leverage with them because he was their number one client in his other job. He trusted them.

And the third thing was that we were serving a very obscure industry. The structured credit market is enormous in terms of dollars but not in terms that people understand how it works. It’s not like a consumer market where there is an obvious way to copy the product and go to market with a clone.

Yurij: This was exactly what created an opportunity for DealVector.

Mike: Yes. It’s not the kind of content that you can find on Pinterest. I could not get any funding from VCs.

Yurij: Because they don’t understand. And they don’t invest in things they don’t understand.

Mike: Yes. So I ended up raising my money in New York. I’ve mitigated the IP loss in three ways:

• • the subject matter itself

• • my trust in Talentica
  • the technical knowledge

Yurij: How about the time zone?

Mike: 13 and a half hours is a big time zone difference. We also, however, had a 3- to 8-hour time zone shift with our clients, who were mostly in New York and London. So I started to work quite early every day, with calls at 6 a.m. my time, 6.30 p.m. Pune time. It was tough, but the world has shifted – let’s embrace that.

We never had enough money to go to India. But the level of a personal relationship with our developers we built over Skype was amazing. I know them, I consider them friends even though I’ve never met them. And I definitely consider them DealVector employees and team members even though they are technically contractors.

It is astonishing how the world has shifted. I never met anyone from my team, but I consider them friends.

When I think back to being a kid, I remember how expensive it was to call my relatives in London from the East Coast. Now I’m calling India with video for free. It’s astonishing.

Yurij: If you sum up this experience from all types of interaction with people, do you have the moment when you thought, “There would be so great to have a tool or an app to solve this? Probably I would build it myself.”

Mike: I was astonished at screen sharing. I think screen sharing and voice are the most critical elements. You can mark up, you can write comments live, and so on. Currently, we’re using Skype to communicate and Jira to track bugs. We also use join.me for client demos.

We didn’t yet get to the scale of a 200-person shop. I ran the whole business without a single onshore technical resource. It was sometimes nerve-wracking, but we were able to make it work.

Yurij: Well, Mike, I think this is great. So the problem of cultural differences. It manifests itself in all types of ways – the motivation of the team, the way it’s managed, the communication – are these lost in translation or not? How do you approach that?

Mike: I heard a lot of stereotypes and clichés when I was looking for an offshore development team. Some said that Ukrainians are difficult, or that Indian developers are passive, building just whatever is in the product requirements document without questioning it in any way.

From my own, personal experience working with Talentica, these stereotypes couldn’t have been further from the truth. They were extremely proactive. They actively collaborated with us, bringing new ideas to the table, pushing us towards a number of improvements over our original ideas. We are applying for patents that emerged directly from their work and their creativity in solving complex technical issues.

As a result, none of the cultural risks that I heard about came true. My team members were highly motivated and engaged, and they were invaluable partners in the product development process.

Looking for a dedicated remote team to outsource your development to?
Browse full-stack development teams on YouTeam, available to start within the next 2 weeks.