Startup Lessons from the English East India Company


The Company of Merchants of London trading into the East Indies was founded in 1600 as a scrappy startup trying to disrupt a spice trade dominated by the Dutch. Over the next two centuries it evolved into a solid financial performer, a regulated monopoly and then into a branch of government.

Please put aside for the rest of this post any concerns about the various and many reprehensible things done by, or in the name of, this company. Just look at it from the perspective of what it can tell us about growing and evolving a business.

Turns out that plus ca change. Much of what we obsess about in the world of startups today would be very recognisable to an observer in the 1600’s. In the 21st Century how companies get created and develop is not all that different to 400+ years ago. Shouldn’t be surprising as ultimately we are still people and people haven’t changed all that much over the centuries.

The quotes below are from John Keay’s The Honourable Company.

On being an early stage investor

The first voyage didn’t live up to founder or investor expectations but it was a pretty impressive feat nonetheless. Now there’s a sentence that could easily apply to every MVP I’ve seen. It set out in 1601 in search of the spice islands and their cloves. Didn’t quite make it but managed to return in 1603 with plenty of pepper.

[T]he 218 petitioners who in 1600 had become the Company of Merchants of London trading into the East Indies had subscribed for only one voyage. The majority now wanted their money back; they were not amused when instead they were told that for every £250 they had subscribed, £200 must be reinvested in a second voyage. (p25)

Same lesson applies today to any early seed investor. Make sure you’ve kept enough money aside for a top-up later on. Whatever you put in now won’t be enough.

On the importance of dog-fooding

England had one huge commodity at the time: wool. The Company was desperate to find a market for wool and thought that Japan might be a good bet. Unfortunately not so. Keay quotes John Saris, leader of this expedition who in 1613 wrote that:

The natives were now more backward to buy than before because they saw that we ourselves were no forwarder in wearing the thing that we recommended to them. ‘For’, said they, ‘you commend your cloth [wool] unto us but you yourselves wear least thereof, the better sort of you wearing silken garments, the meaner fustians [made from cotton] (p58).

Product Managers take note: use your product and be seen to use it 🙂

On the roller-coaster of investing in a growth stock

“£100 of stock purchased … in 1657 had slumped to £70 by 1665 but thereafter appreciated dramatically. By 1677 it was valued at £245 and by 1683 was selling at anything between £360 and £500.” (p170)

Now look at the stock price chart of Facebook 2013 vs Facebook 2016.

On becoming a solid financial performer

If the 17th Century was about a scrappy startup trying to figure out its business model, in the 18th Century the bean counters took over.

By 1710 it was regularly sending to the East ten to fifteen ships a year, each of around 300 tons… Thirty years later the number of sailings had risen steadily … to around twenty, each ship being usually of 490 tons. (Over 500 tons and the ship’s company had to include a chaplain.) … Naturally prices and profits fluctuated but there was none of the erratic boom and bust so typical of the previous century. Shareholders came to expect their annual 8 percent dividend and when in 1732 it was proposed to reduce it to 6 per cent there was such an outcry that the directors had to think again. India stock had become the eighteenth-century equivalent of a gilt-edged security, much sought after by trustees, charities and foreign investors. (p220)

Interesting to see the emphasis move from capital appreciation to income generation.

On dealing with the haters

Naturally success breeds detractors and the Company had plenty of those. From a 21st Century perspective it’s really interesting to see 17th Century people struggling with trying to make sense of international trade. When the first voyage returned in 1603 it faced some hostility back home: “Already there were those who failed to see how exchanging precious bullion for an inessential condiment like pepper could possibly be in the national interest.”(p24).

One recurrent criticism … was that the Company must be impoverishing the nation since it exported treasures and imported only luxury items. In the case of Indian cottons these were manufactured goods which must be killing off English manufactures… But in 1620 Thomas Mun, a director of the Company, met … objections in his Discourse of Trade unto the East Indies. Mun argued convincingly that there was nothing inherently wrong with exporting precious metals provided that values of such exports was less than the value of the imported goods. ‘For let noe man doubt that money doth attend merchandise, for money is the price of wares and wares are the proper use of money, so that coherence is inseperable.’ (p119)

We may not be so worried about exporting gold any more. But there are plenty of similar debates about trade vs. protectionism still going on.

On the role of telling a good story to the financial markets (and of investing in yourself)

Robert Clive, already a powerful presence in the Company, was sent from England to run their interests in India in 1764. He was so excited at the opportunities he found that he “gave instructions for ‘whatever money I may have in public funds or anywhere else and as much as can be borrowed in my name’ to be invested in Company stock.” (p376)

Clive was massively over-optimistic about what he could deliver. The huge annual surplus he foresaw was “sweet music to the ears of the directors” and when news of these predictions reached London in 1766 they had a profound effect on Company stock.

[T]he Company’s stock, a normally unexciting performer on the financial markets, suddenly began to climb. It added …. about five percent in a single day and it went on climbing, nearly doubling its value over the next eight months. Clive’s friends …. bought heavily; but as word of his optimistic calculations … leaked out, outside investors also leapt on the bandwagon. On the Amsterdam and Paris markets the bubble went on growing and as the wilder speculators moved in, the greater became the pressure to keep the bubble from bursting.

An obvious way of preventing such a catastrophe was by boosting confidence still further with a hefty increase in the annual dividend … Accordingly, in September 1766, the General Court of Proprietors moved from an increase from six to ten percent… As a result, stock values continued to climb. (p378)

Turns out he had been massively over-confident and the stock price crashed later on. But just goes to show much people have always been driven by story telling and their animal spirits.

And finally, on how to eventually turn philanthropist

Of those who remained in the Company’s service the American-born Yale brothers proved the shrewdest operators. In the late 1680s Thomas Yale handled their affairs in Siam while Elihu Yale maximised their profits as Governor of Madras. Eventually both attracted the Company’s censure and were dismissed for abusing their positions. Elihu was not, however, disgraced and … he was able to retain his Indian fortune. Part was donated to his old school, then known as His Majesty’s College of Connecticut. In 1718 the grateful trustees renamed it ‘Yale College’ in his honour. (pp199-200)



Impress your CTO – avoid these boring complaints

Here are some of the most boring complaints I hear.

  • No-one knows how it works
  • You can’t measure the quality of what I’m doing
  • It’s because of all of our technical debt
  • We need to re-write this from scratch

They each contain an element of truth but at the same time they manage to completely miss the point. Hence boring.

No-one knows how it works

This really means “I don’t know how it works and nor does the person I usually work closest with”. I once saw a developer spend a huge amount of time trying to recreate, by reading the friendly source, the possible state transitions for a particularly key entity. Because “no-one understood it”. This had two problems:

  1. He may have missed something
  2. By reverse engineering requirements from the working code, what he ended up describing might have included bugs rather than how the feature was supposed to work.

And in this particular instance I could have pointed the developer to one person still in the business and one person who had left but would still be helpful. Next time you’re tempted to assert “no-one understands these state transitions” just change it to a question: “Is there anyone either on the team here, or who has left but is still friendly, who can help me understand how these state transitions are supposed to work?”

You can’t measure the quality of what I’m doing

This is invariably an attempt to hide something. I once worked with a team who didn’t report their test coverage because the lead developer felt that software is too complicated for a metric as simple as test coverage to be meaningful. We debated the subject and eventually agreed that although 100% coverage is probably not that meaningful, it is worth at least knowing where you are. Where were they when they measured code coverage? About 15%. I was amazed. Here we were debating the costs and benefits of 90% or 100% code coverage and all the time we were staring 15% in the face. I cannot think of anyone who would seriously argue that code coverage of 15% is in any way acceptable. For sure, you can’t measure everything, but the skill of a good developer is in helping finding a useful metric to use. For example on a recent project we agreed on a simple metric that if RubyCritic gives us an  A or a B grade then that’s good, if it’s any worse then we need to know why. It’s not perfect but it’s a lot better than hiding behind “you can’t measure what I’m doing”.

It’s because of all of our technical debt

As an experiment, I once agreed with a team to spend one month just doing technical debt cleanup. The results? Nothing noticeably better or faster for the users, nothing notably better quality as far as the QA people were concerned, no metric to show anything had improved, and I was still getting the same developers 3 months later making the same complaints about technical debt. The reality is that there will always be technical debt of some shape or form. Just like real world debt, some technical debt can be good if it helps you achieve other ends that you couldn’t otherwise achieve. Better developers would have a plan that says, for example, “Technical debt in module X is causing us problems, in order to fix those we will need to do Y”. This is better because it is specific and measurable and, if defined well enough, deliverable.

We need to re-write this from scratch

Stop thinking that. It’s a dreadful idea. Whenever you think of re-writing you are thinking of the 20% of the system that is a PITA to maintain. You’re not thinking of the 80% of the system that you will also need to re-write. I remember one project where a 5-month re-write was still going on 18 months later, still with no end in sight. And another where a re-architected system was being built in parallel but wasn’t able to keep up with the new features being added to the “legacy” platform. In shoert I’ve never seen a complete re-write that people were glad to have done. If you do need to make dramatic changes then you will need to find some way to change very specific parts of the application one by one. It will take a very long time: make sure you do your homework before advocating this.

Impress your CTO – Define your own NFRs

In the last instalment I talked about unspecified requirements. These are the ones that your product owner takes for granted: Of course the system should export to Excel; of course it should authenticate with Facebook; of course the system should load pages blazingly fast irrespective of how much data is thrown at it.

The most common of these unspecified requirements are the Non-Functional Requirements (NFRs). And the most common of these NFRs is “how long should the response time be”. So I find it surprising that response times are very rarely (if ever) mentioned during requirements definition work. Avoiding the topic early in the project is a sure way to have problems later on in the lifecycle.

It’s not uncommon to experience a conversation like this:

Sales: “This software is dreadful, it just took forever to load the dashboard in a crucial demo”
Dev: “Let’s see what’s up… oh yes you created a wizzabanga with 38 different permutations”
Sales: “Well yes of course I did. Then it took forever to load into the dashboard. Your software sucks.”
Dev: “But we didn’t have any NFRs”
Sales: “What’s an NFR”
… some tedious conversation ommitted ….
Dev: “So give me an NFR”
Sales: “OK, I want the page to load up in 200ms even if I’ve got 1000 wizzabangas each with 100 permutations”
Dev: “Hmmm… going to cost you”


It’s meaningless to ask your user base for open-ended NFRs. Clearly they want everything to be really fast and really easy and really secure and ready next week. Much more useful would be for you to set out some reasonable NFRs that you think are deliverable in a reasonable timeframe and, even impose some sensible limits or warnings in the system to ensure those NFRs are supportable. Then at least you have an NFR, even if it’s one that you created.

For example if you think it’s reasonable for the page to load “fast enough” if your wizzabanga have up to 10 permutations then either impose a limit in the UI, or even just a sensible warning, “e.g. we recommend that you have no more than 10 permutations in your wizzabanga. You can add more but please note that you will need to be patient when loading larger wizzabangas.”

Impress your CTO (3)

Imagine the following conversation between a product owner and developer

Product Owner: “I want a CRM system”
Developer: “What does that do?”
PO: “It’s a customer database that lets me manage and report on my communications with my customers”
Dev: “That sounds easy, I’ll build you one this iteration”

One week later …

Dev: “Here you go. You log in here and here’s a screen where you can add a record for each customer. When you click into a customer record you can also add some notes for each time you’ve talked to them”
PO: “Wow, you did all that in a week, awesome. Now let’s add in the ability to make some notes for future calls that I need to do and a screen to show what tasks I have upcoming”
Dev: “No problem”

One week later …
PO: “This is so cool”

Brand new projects often start like this. But it doesn’t take long for fatigue to kick in. A few more iterations and all of a sudden you’re getting bogged down in details like:

  • Download to Excel
  • Upload from Excel
  • The fact that you should really be validating postcodes
  • And show the location on a map
  • And have better collaboration facilities
  • And handle customer segmentation
  • Ability to handle email templates
  • And initiate voice calls
  • And route incoming calls to an appropriate agent
  • And let someone apply a credit to a customer’s account
  • etc, etc, etc

At this point you start to realise why no-one sane would build their own CRM.

The Importance of Unspecified Requirements

You see you have functional requirements and you have non-functional requirements. But beyond all of these you have the unspecified requirements. These last ones are really important because your product owner considers them so obvious that they aren’t worth mentioning. Of course your CRM system has to handle loading records from Excel – only a buffoon would not know that!

The solution isn’t to insist on 100% detailed specifications before you start building. That way another type of madness lies. Nor should you consider your job well done because each week you have built what your customer asked for. The best developers are the ones who deliver the best working software, which is not as simple as building what was written down in the spec.

Worry about their unspecified requirements before you get too far down any path. It doesn’t have to involve much coding (if any). If someone asks you to build a CRM then do a sort of throwaway prototype first. Not one that involves any coding. (I’ve seen some great throwaway prototypes written using Excel). Why not get a one-month license to Salesforce (or whatever). This is a great way to get to see really what features they value, where their frustrations are etc. Then if you discover that Salesforce is the right answer for them then thank your lucky stars that you’ve had a narrow escape from attaching a massive bespoke millstone round your neck for the rest of the time with your company. And if you discover that there is something really special about your requirements, well, then you can build a truly great application that really addresses the real problems your users are facing.


How to make 3000 look like 8000, or #marketing

See below how CarGiant, a UK-based retailer of used cars does it.

First off, the organic search results:

Car Giant organic search results

If you search for Car Giant they have already anchored in your mind that they have over 8000 vehicles


So now you land on the home page and note how the “over 8000” has now changed to “up to 8000”. That could be a whole lot of a smaller number. So let’s do a search for all vehicles up to the maximum price available.


And there you go, just under 3000 cars. Which is definitely “under 8000” as promised, but by this time you’ve still got in your head that Car Giant is a truly giant organisation with 8000 or more vehicles to sell you.

See also


Valuing Sweat Equity, 1100 AD

Find a valuation for a startup is a thorny and emotive subject. How much is the idea worth? How much is the founder(s) working for many months without any income worth? How much is your advisory board worth?

So I enjoyed coming across this keep it simple approach from Genoa around 1100AD

From David Abulafia, The Great Sea, p277

Often … merchants engaged in what they simply called a societas, or ‘partnership’, where a sleeping partner would invest three-quarters of the total and his (or her) colleague would invest one quarter, while also agreeing to travel to whichever destination had been agreed, and to trade there. On his return, the profits would be divided in half … [A]nother arrangement became even more common: the commenda, where the travelling partner invested nothing more than his skills and services, and received a quarter of the profits.

Using this model you come out with the “sweat” part of the valuation being worth between 25% and 33% and the “investment” part representing the rest. Of course this doesn’t take into account that in 1100 being the travelling partner put you at risk of serious bodily damage rather than just a few all-nighters and stressful pitches. Nor does it take into account the fact that there are bound to be differences between fitting out a ship and cargo for a sea voyage in 1100 and turning a software MVP into a self-sustaining business.

But (coincidentally?) the relative weights between cash and sweat do feel about right.

Impress Your CTO (2)

People expect software to “just work”. You can guarantee that it won’t
“just work” when someone decides to throw more data at than you expected. So my 2nd tip is:

Enforce Sane Limits

From a developer point of view it makes sense to think in terms of 1 to Many or Many to 1. Why put in extra work to enforce some limitation when you can have unlimited flexibility for free?

Because the real world doesn’t work that way and it’s more important to model the real world than it is to create infinite flexibility. Some good reasons:

  1. Usability
  2. Performance
  3. Commercial reasons


The more “many’s” in your one to many, the more UI real estate you need to think about. Pagination, sorting, searching, exporting lists to Excel. Maybe favouriting so that people can shortlist the results because they can’t make sense of the whole list. Nothing here is super-complicated to code, but given that the scarce resource in most tech operations is developer time, as a great developer you will be ensuring that you are spending your valuable time on the most value-add activities.


Be honest. You aren’t about to write comprehensive automated performance tests. If you allow people to add unlimited items then eventually someone will do so and, probably sooner than you expect, you will experience serious performance issues. Which then means that you need to be spending valuable developer time addressing those performance issues because by the time you have enough traction to have performance issues you aren’t going to be able to withdraw the poorly performing feature [*].

Commercial Reasons

Maybe a surprise to see this as a reason but it may be the one you would do best to remember. The simple point here is that if the standard version of your product allows the user to add up to 15 items to a Thingamy then not only do you lower the risk of performance issues etc but you have a built-in mechanism that your product managers can use to upsell your customers to the next subscription level: “You want to handle more than 15 items? Let me put you through to our Enterprise Sales team”. If there is demand for the feature and customers will pay for it then fantastic – it will be a great feature to spend some real effort and attention to and give it a stunning user experience that performs really well.


I’m not saying to do anything complicated in your database. Leave the database handling a 1 to Many relationship. Just put check somewhere in your business logic. Next time you are discussing a feature with your product owner and you are thinking about the many side of the object model, just ask the question: “Would 5 be enough?”

[*] This is a case of “do as I say, not as I do” here. In my own side project which allows a user to merge and stitch together data from different Excel files I didn’t impose any limits. I asked some friends and family to test it and the second thing my brother did was try to crash it. It worked. So now I’ve implemented some limit checking.