About Me

Im currently CEO and co-founder of Mondo - a new smartphone-based bank.

I previously co-founded Boso.com and GoCardless - both companies were
accepted onto Y Combinator.
GoCardless has gone on to raise over $12m from Accel, Balderton & Passion
Capital, and is currently HQed London.
In 2013, along with my cofounders, I was nominated one of the top 5
Entrepreneurs under 30 by the European Commission. I write code of various
flavours - you can find me on Github.
I blog here at tomblomfield.com about software engineering & startups.
You can contact me at tomblomfield@gmail.com or @t_blom.

Some of the most thoughtful startup-related articles on the web

How to Make Pittsburgh a Startup Hub

Life is Short
Economic Inequality
The Refragmentation
Jessica Livingston
A Way to Detect Bias
Write Like You Talk
Default Alive or Default Dead?
Why It's Safe for Founders to Be Nice
Change Your Name
What Microsoft Is this the Altair Basic of?
The Ronco Principle
What Doesn't Seem Like Work?
Don't Talk to Corp Dev
Let the Other 95% of Great Programmers In
How to Be an Expert in a Changing World
How You Know
The Fatal Pinch
Mean People Fail
Before the Startup
How to Raise Money
Investor Herd Dynamics
How to Convince Investors
Do Things that Don't Scale
Startup Investing Trends
How to Get Startup Ideas
The Hardware Renaissance
Startup = Growth
Black Swan Farming
The Top of My Todo List
Writing and Speaking
Defining Property
Frighteningly Ambitious Startup Ideas
A Word to the Resourceful
Schlep Blindness
Snapshot: Viaweb, June 1998
Why Startup Hubs Work
The Patent Pledge
Subject: Airbnb

Founder Control
Tablets
What We Look for in Founders
The New Funding Landscape
Where to See Silicon Valley
High Resolution Fundraising
What Happened to Yahoo
The Future of Startup Funding
The Acceleration of Addictiveness
The Top Idea in Your Mind
How to Lose Time and Money
Organic Startup Ideas
Apple's Mistake
What Startups Are Really Like
Persuade xor Discover
Post-Medium Publishing
The List of N Things
The Anatomy of Determination
What Kate Saw in Silicon Valley
The Trouble with the Segway
Ramen Profitable
Maker's Schedule, Manager's Schedule
A Local Revolution?
Why Twitter is a Big Deal
The Founder Visa
Five Founders
Relentlessly Resourceful
How to Be an Angel Investor
Why TV Lost
Can You Buy a Silicon Valley? Maybe.
What I've Learned from Hacker News
Startups in 13 Sentences
Keep Your Identity Small
After Credentials
Could VC be a Casualty of the Recession?
The High-Res Society
The Other Half of "Artists Ship"
Why to Start a Startup in a Bad Economy
A Fundraising Survival Guide
The Pooled-Risk Company Management Company
Cities and Ambition
Disconnecting Distraction

Lies We Tell Kids

Be Good
Why There Aren't More Googles
Some Heroes
How to Disagree
You Weren't Meant to Have a Boss
A New Venture Animal
Trolls
Six Principles for Making New Things
Why to Move to a Startup Hub
The Future of Web Startups
How to Do Philosophy
News from the Front
How Not to Die
Holding a Program in One's Head
Stuff
The Equity Equation
An Alternative Theory of Unions
The Hacker's Guide to Investors
Two Kinds of Judgement
Microsoft is Dead
Why to Not Not Start a Startup
Is It Worth Being Wise?
Learning from Founders
How Art Can Be Good
The 18 Mistakes That Kill Startups
A Student's Guide to Startups
How to Present to Investors
Copy What You Like
The Island Test
The Power of the Marginal
Why Startups Condense in America
How to Be Silicon Valley
The Hardest Lessons for Startups to Learn
See Randomness
Are Software Patents Evil?
6,631,372
Why YC
How to Do What You Love
Good and Bad Procrastination
Web 2.0
How to Fund a Startup

The Venture Capital Squeeze

Ideas for Startups
What I Did this Summer
Inequality and Risk
After the Ladder
What Business Can Learn from Open Source
Hiring is Obsolete
The Submarine
Why Smart People Have Bad Ideas
Return of the Mac
Writing, Briefly
Undergraduation
A Unified Theory of VC Suckage
How to Start a Startup
What You'll Wish You'd Known
Made in USA
It's Charisma, Stupid
Bradley's Ghost
A Version 1.0
What the Bubble Got Right
The Age of the Essay
The Python Paradox
Great Hackers
Mind the Gap
How to Make Wealth
The Word "Hacker"
What You Can't Say
Filters that Fight Back
Hackers and Painters
If Lisp is So Great
The Hundred-Year Language
Why Nerds are Unpopular
Better Bayesian Filtering
Design and Research
A Plan for Spam
Revenge of the Nerds
Succinctness is Power
What Languages Fix
Taste for Makers
Why Arc Isn't Especially Object-Oriented
What Made Lisp Different
The Other Road Ahead

The Roots of Lisp

Five Questions about Language Design
Being Popular
Java's Cover
Beating the Averages
Lisp for Web-Based Applications
Chapter 1 of Ansi Common Lisp
Chapter 2 of Ansi Common Lisp
Programming Bottom-Up

Technical Interviews
Over the last year, weve done dozens of interviews that involve some kind of
technical element. Weve hired some great programmers, and we're looking for
more
Weve spent a some time thinking about how we run these technical interviews
(as have others), so I wanted to touch on the kind of things we look for, and what
the interview process at GoCardless looks like.
CV & Github
We ask everyone to provide a (brief) CV and links to their github account or
other examples of code theyve written. One page is usually sufficient - we want
know about;

Education
Previous jobs & specific responsibilities
Passion for development outside work. This is the area where people can
really shine. Tell us about a hack-weekend project, open-source project or
technical conference presentation that youve given.

Product & Business Case Studies

Even when interviewing for technical roles, we spend a fair amount of time
talking about business & product issues. We think we can build a better company
by working with people who are self-sufficient, take initiative and get stuff done.
This doesnt mean you need a degree in business microeconomics, but you
should have thought about questions like what impact might feature x have on
sales conversion, customer churn or revenue-per-user?
Another favourite is We have problem Y that is costing us z per user. What are
the technical solutions to this problem? And what are the business solutions?
Which would you implement first, and why?
Technical Interviews
This has been discussed at great length, but I wanted to throw in our two cents;
We use a couple of simple programming exercises - usually involving some kind
of choice between recursion or looping, with a discussion of which might be
more useful & why.

I personally think exercises like implementing Pascals triangle (where the

candidate is given a definition of Pascals triangle, a choice of language and
access to API documentation for that language) are really great negative filters
that reveal whether a person can actually code.
Were looking for something like
def pascal_loop(n)
triangle = [[1]]
(0..(n-2)).each do |i|
this_row = [1]
(1...triangle[i].size).each do |j|
this_row << triangle[i][j-1..j].inject(:+)
end
triangle << (this_row << 1)
end
return triangle[n-1]
end

We also talk through various theory questions, focussing on concepts behind web
programming (transfer protocols, request-response cycles, persisting data,
caching), database & systems design. We also touch on algorithms, but Im not
sure how useful this is, particularly for someone without a formal CS degree.
How do you run technical interviews? Comments welcome.
If youre looking for a developer position in London, apply now!

I hate meetings
It will be no surprise to those I work with to hear that Im not a big fan
of meetings. I wanted to lay out a few problems we had with meetings, and the
ways in which were trying to solve them.
Startups Operate in Conditions of Extreme Uncertainty
By definition, theres always uncertainty at a startup. You need to work out what
youre making and whether anyone actually wants it.
This uncertainty makes most people uncomfortable, which is natural. A tempting
solution is to schedule meetings to debate this uncertainty endlessly, as if it can
be made certain by the power of thought alone. This is particularly the case for
people with backgrounds like mine, who spent time at university and jobs in
which we were actively encouraged to theorise without seeking empirical
evidence. Instead, work out how you can validate your assumptions as quickly as
possible, and make that happen.
You can sometimes gain empirical evidence on which to make a decision whilst
expending a very small amount of time & energy.

The TripAdvisor 404 Test - Put a link to the new feature on your website,
but Before you build the darn thing see how many people click it. It
goes nowhere, it says broken link to the user [but] your log file says how
many people [check it out]It solves umpteen meetings worth of powerful
debate and logical arguments.

Dropboxs Demo Video - A 3 minute demo video on Hackernews

prompted 12,000 digs, and tens of thousands pre-registrations. This gave
Drew Houston the validation he needed to spend another year creating a
market-beating file-syncing & backup service.

An early-stage payments startup (not ours!) wondered whether merchants

would use a monthly subscription billing service in addition to regular oneoff payments. So they launched the service with a minimal back-end,
knowing that if it took off, theyd have 30 days to build the functionality.

You wear every hat

Working at an early-stage startup, there are a thousand things to do. Youre the
recruiter, HR person, accountant, office manager, receptionist, programmer &
cleaner - and you have to make all the decisions associated with these roles. But

its sometimes tempting to devote more time than necessary thinking about (and
discussing!) these decisions.
In reality, the only important question for early-stage startups is almost
always "does anyone want what were making? Most of the other stuff doesnt
need to be decided yet. "What shall we put in our cashflow forecast?, Wheres
our new office going to be?, In 3 years, what do we want our brand position to
be? They are all important questions, but probably not yet.
If a decision doesnt have any practical impact on what your team is doing this
month, just postpone it (and the associated meetings). If you do eventually have
to make the decision, youll have more information at your disposal. If youre not
spending the majority of your time trying to solve the one most important
problem your business faces, it could be a sign that somethings wrong.
Meetings kill productivity
A lot of smart people have written extensively about this subject, and I dont
have much more to add. I reckon it takes me about an hour to really get up to full
speed when developing something challenging, and it takes a minimum of 2-3
hours to produce anything meaningful. So a meeting halfway through an
afternoon bazookas productivity for at least half a day.
Some thoughts
After a year of running our startup, weve come up with several ways of avoiding
unnecessary meetings and keeping necessary meetings as brief as possible

Ask: Is this discussion going to result in a decision that practically impacts

our priorities in the next 2 weeks? If not, postpone it.
Any discussion that goes over 5 minutes has to move to a meeting room.
This isnt because we like having meetings in meeting rooms; quite the
opposite. If the discussion isnt important enough to warrant disrupting the
team, then postpone it.
Have one meeting every two weeks at which you review any of the longerterm decisions and make sure everyone on the team knows what the
company is focussing on

If you want to find out more about how we work, come and say hello

Syntax Highlighting on tumblr

Ive decided to write about various startup and ruby-related stuff. So syntax
highlighting is pretty vital.
def multiply(a,b)
a * b
end

You can read about how to implement syntax highlighting here

Automate Everything
Performing manual, repetitive tasks enrages me. I used to think this was
a corollary of being a programmer, but Ive come to suspect (or hope) that this
behaviour is inherent in being human.
But being able to hack together scripts simply makes it much easier to go from a
state of rage to a basic solution in a very small amount of time. As a side point,
this is one of the reasons that teaching the basics of programming in schools is so
important. Its hard to think of any job which wouldnt benefit from a few simple
scripts to perform more automation.
When were hiring, even for non-developer roles, we look for this kind of
mentality - its extremely useful, especially when building a software businesses,
if costs dont scale linearly with revenue. The more we can invest up-front in
automation, the less time our team has to spend on performing stupid, manual
tasks. As we add more employees, the benefits are compounded. And less rage
generally makes the workplace a much happier place.
I encountered a practical example earlier this week. It was time to submit
expense reports, and I could feel the rage starting to build up. For some reason,
our accountant decreed that we had to fill in a spreadsheet, line-by-line, for every
expense item. It looked a lot like this.

Presumably, hundreds of millions of people have to do this every month, costing

millions hours of lost productivity. And in most companies, its because a wellmeaning HR or Finance person has said that It Must Be Done. But if that Finance
person had a modicum of programming experience, they might be minded to try
to find a better way. Thats is what I mean by hiring people with this kind of
mentality. We dont want anyone wholl lump some stupid task on the rest of the
team because theyve not got the mindset to think about automation in a sensible
way. Even if they cant programme the solution themselves, they need to be able
to figure out pretty quickly that a better solution must exist

After briefly raging out, I decided to do something about this particular problem.
1 - quickly define the requirements;

Record details of every expense item including date, amount & description
Be able to query the list to produce reports (by month and/or person
submitting the receipt)
Keep copies of receipts for HMRC

2 - think about how receipts fit into our workflow at the moment, and the
major problems

Receipts can be physical (till receipt for lunch) or electronic (Rackspace

email)
They can pop up at random points in they day - not conveniently all at the
same time every month
People have to store small pieces of paper for up to 30 days. Unreliable
People then have to spend an hour or two each month going through
thousands of emails and hundreds of small pieces of paper to find the
receipts, remember what theyre for, and write them down one-by-one. At
least the spreadsheet auto-sums the amounts to a total Inefficient!

3 - Apply a modicum of brainpower to automate the pain-points.

To avoid the unreliability of storing small pieces of paper and the inefficiency of
examining thousands of emails, perhaps we could store them all in once place,
electronically. This place could be an email account called something
imaginative like expenses@mycompany.com.
To avoid having to go through each receipt one-by-one, perhaps some kind of
machine could parse relevant information out of each email and persist it
somehow. Perhaps a database might be useful. To produce the report, perhaps the
database could output certain information based on some kind of structured query
language. So that the people at HRMC dont suffer an instantaneous and fatal
brain-explosion when we send them the data, perhaps we could separate values
with a comma, save them all in a file and advise HRMC to open the file with
their preferred Microsoft spreadsheet program.
As a side note; In the interests of not re-inventing the wheel, its generally a good
idea to check if someone has solved this problem before. I decided to roll my
own in this case because I was interested in learning about email handling after
watching this great railscast from Ryan Bates. And because paying $9 per month

per user for something I could probably write myself in a couple of hours seemed
silly.
Technical Details
If youre interested in the technical details, I used a ruby gem called
Mailman, hosted on Herokus new cedar stack, to poll our POP3 mail server
every minute. Attachments (pdfs, photos etc) are saved to AWS S3, and simple
details of each receipt are stored in a postgres database. A Campfire gem called
Tinder immediately alerts our company chat room that someones spent some of
our hard-earned cash (just for amusement, really), and a very simple Rails app
hosted on Heroku makes the data available in HTML or CSV, which can be
queried by date-range or employee.
Emails are required to have a line similar to Amount 12.50. Running OCR on
photos of receipts and detecting the right line to take the Bill total from seemed
like too much effort. We might switch to mechanical turk if people find this step
troublesome.
If theres any interest, Im happy to stick the code on github.
Conclusion
Dont put up with repetitive, manual tasks - automate them! Its the
jedi hacker way.

Automating Customer Service at a Startup

Customer service can make or break a company; it has been one of the key
differentiators as a new generation of startups seeks to compete against
incumbents. While people remember examples of awesome customer service, the
opposite is also true.
At GoCardless, we decided early on that we wanted customers to have a fantastic
experience with the service, so that theyd hopefully tell their friends about it.
Unfortunately, being a 5-person startup, we dont have the luxury of a massive
customer support team. What we do have, however, is access to a bunch of great
tools that make running a startup much, much easier. These tools, combined with
some really smart developers and the instinct to Automate Everything, results in
a pretty great customer experience.
I wanted to spend a little time going through those tools, and demonstrating how
they can be combined with a sprinkling of API magic powder to produce
something vastly greater than the sum of their parts.
With these super-charged tools, we find one full-time person can generally run
customer support on their own, leaving the other 4 to work on the product.
Weve also consciously made the decision that everyone should do some
customer support - even engineers. It really helps people stay in touch with what
our customers are saying, and lets us react quickly as a team to common
problems that emerge.
I should note that we cant claim credit for this idea - it was stolen wholesale
from a great talk the Wufoo guys gave at a Y Combinator dinner.
Campfire
$12/month for basic version. As a relatively technical company, our Campfire
rooms form the central communications hub for our company. Its basically like
hosted IRC with a few bells & whistles like file uploads & code snippet support.
You can choose to make rooms public or private, and generate direct links that
will enable customers to chat with you directly through their browser. We do
most of our technical customer support through these rooms. And as a small
community has built up, we find other developers helping with each others
problems. Awesome!
A lot of other services have hooks that will send campfire messages into
specified rooms via the API on certain events. For example, Github has a hook

that sends new issues & commit messages into our private developer room. There
are a few more custom-built ones that Ill get onto later!
If youre using ruby, Id recommend checking out the Tinder gem, which
provides a convenient wrapper to the REST API.
I can also highly recommend hubot, a Campfire bot written in Node by the
Github team. Its very simple to write extensions to perform simple actions like
trigger server deployments.
Zendesk
$24/month per agent for standard version. While pretty expensive, Zendesk
offers a variety of free trials, particularly for startups. It helps companies run
email-based customer service desks, turning inbound emails into tickets that
can be responded to or re-assigned across available agents.
It was the first customer service product we decided to use properly, and now
forms the core of all of our written communication with customers - particularly
email & twitter. Its simple to add tags to tickets automatically or manually, so
we can count the number of requests for Repeat Billing vs European Rollout
at the end of every month. You can also get a bunch of metrics like response
times & satisfaction rates, but at the moment were just focussing on keeping our
heads above water!
We considered using the in-built Campfire integration to alert our Campfire room
of new tickets, but quickly realised this would be more annoying than useful as
we approached 30-40 new tickets per day.
Olark
$15/month for 1 operator. Discounts for startups. This provides live text chat on
our website - the little Chat Now box you see in the bottom-right of your
screen at gocardless.com. I was initially really skeptical of Olarks value, but
after using it for a month, Im a convert. You can see where a user has come
from and stay with them as they navigate through your site (including
notification of which page theyre currently viewing), which makes it super easy
to solve problems step-by-step.
With built-in Zendesk API integration, you can also save conversation transcripts
in Zendesk as solved tickets and add tags to them - which makes running
aggregated metrics really simple. Its as simple as typing !tag International in
the chat window. If you want to drill down even deeper, you can run metrics by

page - eg 70% of queries from people viewing page X were about Pricing,
whereas most people on page Y were looking for more information about
International Support.
We generally use Adium or a GChat plugin to access Olark.
Phone Support
The one weak link was our phone support - we previously used a Skype number
that forwarded to mobile phones. Unfortunately, we had a number of problems
with the solution - call quality was really low, sometimes calls didnt forward or
just randomly dropped, and collecting voicemail was a nightmare. Id looked at
the Zendesk voice features, but they were only available in the US & Canada.
Then, a couple of months ago, some guys from Twilio moved into an office
nearby. Id been wanting to try out their service for a while, so we decided to
hack together a simple customer service phone app. A few hours later, we had a
pretty decent phone system with voicemail.
Whats more, weve built-in a tool to check whos available in our private
Campfire room to take the call. If someone doesnt pick up, it will try one of our
other agents idling in Campfire. It also talks to our Zendesk ticketing system,
notifying us if someone leaves an mp3 voicemail, so that someone always
follows up. Sweet!
One small gripe is that voice-to-text transcription is terrible, to the point of being
unusable. Maybe its my English accent, but I couldnt get above a 50% accuracy
rate. So we turned it off and stuck with voice recordings.
A landline number costs almost nothing, but the call forwarding to our agents
(right now, me & my co-founders!) mobiles comes in at $0.14/min, which isnt
cheap.
Ive posted the technical implementation details here
Conclusion
The key for us is that consumers can contact us however they like - phone,
twitter, email or live chat - and we can respond quickly using tools that were
familiar with.
Metrics are also really important - we want to be able to track the number of
queries by channel and easily categorise them by subject matter. This allows us
to fine-tune our landing pages to address frequently asked questions more

directly and also prioritise new product development according to customer need.
But its vital that this we can do this tagging either automagically or at least inline with whatever were doing. The !tag International Expansion in Olark is a
good example of this. As soon as you need to open a separate list of Feature
Requests and add a +1 to a tally chart, people stop using it.
The two weak points in this regard are Campfire and the Twilio voice app. For
Campfire, we could do a text search on a months logs, or write a simple hubot
extension (!tag International). With Twilio, Ive still not come up with a good
solution. Suggestions welcome!
If you want to work at a startup that hacks Twilio & Campfire apps together
during the week, check out our jobs page!
Discuss this post at Hacker News

Home-Brew Customer Phone Support

This is the technical part of a longer piece on Automating Customer Service at
a Startup
DIY Phone Support
We implemented a home-brew customer service phone line in a few hours with a
basic Sinatra app on Heroku, using the Twilio-ruby gem to generate TwiML
(saving us the pain of writing raw XML) and a simple Campfire gem called
Tinder.
require
require
require
require

'twilio-ruby'
'tinder'
'net/http'
'uri'

The idea was to query our private Campfire room to see which agents are
available, then render the relevant TwiML to get Twilio to forward any inbound
customer calls to the phone number associated with that agent. If the agent
doesnt pick up the call with 15 seconds, it should try the next available agent,
until all agents are exhausted, at which point it should record a voicemail.
known_agents = {
"Tom Blomfield"
=> "+4477XXXXXXXX",
"Jim Beam"
=> "+4477XXXXXXXX",
"Fred Flintstone" => "+4477XXXXXXXX",
# etc
}
campfire = Tinder::Campfire.new 'gocardless', :token => CAMPFIRE_TOKEN
room = campfire.find_room_by_id CAMPFIRE_ROOM
get '/start' do
# Alert Campfire users that there's an incoming call
room.speak "Incoming call from #{request["From"]}"
response = Twilio::TwiML::Response.new do |r|
r.Play "Welcome to GoCardless"
r.Play "Please wait while we find someone to answer your call"
r.Redirect "/call?user=0"
end
# Render the TwiML
response.text
end
post '/call' do
user_id = @params["user"].to_i
# Query Campfire for available agents
available_agents = known_agents.select do |name, phone|

room.users.map(&:name).include? name
end
# Agent we're going to call
agent_name
= available_agents.keys[user_id]
agent_number = available_agents[agent_name]
response = Twilio::TwiML::Response.new do |r|
if agent_name
r.Say "We're connecting you to #{agent_name}"
# Alert Campfire users that we're calling someone
room.speak "Calling #{agent_name} on #{agent_number}"
# Tell Twilio to try to call the agent
r.Dial agent_number, :callerId => '+44XXXXXXXXX', :timeout => 10
# Fallback action if the agent doesn't answer
r.Redirect "/call?user=#{user_id+1}"
else
# No agents left, redirect to voicemail
r.Redirect "/voicemail"
end
end
# Render the TwiML
response.text
end

One gotcha to be aware of is that Sinatra will evaluate the entire script when the
server boots up; any variables you assign (eg, whos in our Campfire room) will
be set once, and used like constants. On the other hand, each controller method
(eg get /start) takes a block; this block is evaluated every time Sinatra serves a
page. Thats why we ask for room.users inside the post /call block - it will
make sure that the list of available agents is up to date.
In reality, we tweaked the above script a little; looping through 5 or 6 different
agents could get a little irritating for a customer, so we limited it to 1 re-try
before diverting to voicemail.
The voicemail script is pretty simple:
post '/voicemail' do
# Tell Campfire
room.speak "No-one answered call from #{request["From"]}!"
response = Twilio::TwiML::Response.new do |r|
r.Say "Unfortunately no one is around to take your call"
r.Say "Please leave a message and we'll get back to you"
r.Record :action => "/goodbye", :timeout => 10
r.Redirect "/goodbye" # if no message is left
end
response.text

end
post '/goodbye' do
# Tell campfire
room.speak "Voicemail from #{request["From"]}.
#{@params["RecordingUrl"]}.mp3"
response = Twilio::TwiML::Response.new do |r|
r.Say "Thanks for your message"
r.Say "We'll get back to you as soon as we can. Goodbye"
end
response.text
end

This records an voicemail thats stored at on Twilios servers, and we output a

link to the recording in Campfire. But to be certain that someone deals with the
voicemail, we wanted to log it as a ticket in Zendesk:
# Insert this into your "goodbye" block.
# Create a zendesk ticket
zendesk from: request["From"], recording: @params["RecordingUrl"]

The zendesk method is just a simple http post to the ZenDesk API using
net/http, which creates a new Zendesk ticket. There is a Zendesk ruby gem, but
it wasnt well supported at the time of writing.
def zendesk(args)
from = args[:from]
recording = args[:recording]
url = URI.parse "http://help.gocardless.com/tickets.json"
req = Net::HTTP::Post.new(url.request_uri)
req.body = {
:ticket => {
:subject => "New Voicemail from #{from}",
:description => "New recording at #{recording}.mp3",
:ticket_type_id => 33, # Zendesk code for voicemail!
}
}.to_json
req.basic_auth ZENDESK_USERNAME, ZENDESK_PASSWORD
req["Content-Type"]= "application/json"
connection = Net::HTTP.new(url.host, url.port)
response = connection.start do |http|
timeout(5) { http.request(req) }
end
end

Thats it!
One thing to note - all the Campfire and Zendesk API calls are
performed synchronously, which increases response time and can leave the caller

waiting around. At the moment, its usually imperceptible, but well

eventually move the API calls to asynchronous methods, probably using Redis.
To find out more about GoCardless, check out our site. If youre a developer and
want to play with Twilio & Campfire APIs at work, apply for a job!

Dont write tests - The Hidden Cost of TDD

Ive been following the TDD/testing debate with some interest; I work at an
early-stage payments startup called GoCardless where we test religiously. Were
not dogmatic about whether the tests come first or not, but code doesnt get
deployed without full unit & acceptance tests. Its saved our skins on more than
one occasion
I wanted to explore the benefits of testing and suggest some situations in which
<heresy>testing may be counterproductive</heresy>
Testing - The Good Bits
When youre working as part of a team on a large codebase, comprehensive
testing is invaluable. If you measure development velocity on a company-wide
basis over the medium-long term, testing provides clear benefits.
Engineers working on one part of the codebase dont have to worry about their
changes having unanticipated knock-on effects in another area. A good mix of
unit tests and acceptance tests means that you can write & deploy code quickly,
without a lengthly QA process.
When stuff does break, unit tests allow you to identify the individual component
thats causing problems. Its fantastic - at GoCardless, no code goes into
production without comprehensive testing & peer code review.
(If that sounds like a place youd like to work, were hiring!)
Testing slows down rapid prototyping
Having said that, there are situations when comprehensive testing just isnt the
right solution. Im not talking about whether tests should come before (TDD) or
after writing code - there are situations where it might be beneficial to write no
tests at all.
The particular situation I have in mind is the ultra early-stage startup struggling
to find traction. The number one priority in this situation is not to write beautiful
code or solve hard technical problems in innovative ways; its to work out what
people people want. You do this by iterating quickly & launching early - just as
its often possible to fake a much more sophisticated or elegant solution by doing
stuff manually, its also possible to write quick, scrappy code that works just
about well enough.

Youll accumulate buckets of technical debt, but its generally ok. If you dont
find traction or product-market-fit, you declare bankruptcy on that technical
debt and just move on to the next iteration.
Once youve found traction, youll likely need to re-write your codebase, but
thats ok as well. At this point, youll have a much clearer idea of what the
product actually does, so writing specs should be much simpler.
As an addendum, I think this conundrum is one reason why outsourcing earlystage tech development is such a terrible idea - any decent web development
shop will generally insist on writing comprehensive test suites, and theyll react
badly if the job spec changes dramatically every 2 weeks. But thats sort of
necessary when youre writing code for an early-stage startup.
Discuss this post at Hacker News !

Peter Nixey: Cook something or get out of the kitchen

peternixey:
I seem to have a lot of conversations recently with people who find themselves in
the kitchen but without the means to cook anything.
As a cook myself they often ask me how to go about finding themselves a chef
who can cook something for them. I ask them why they want to do that and they
tell

Making something people want - The GoCardless story

Im a co-founder of GoCardless, a direct debit payments company in London.
This is the story of our first two years and the people weve met along the way.
Making something no-one wants
One startup I know very well in San Francisco was started by 3 ex-financiers.
Their idea involved an industry in which none of the 3 had any experience - they
wanted to build software to help building contractors bid for big construction
projects.
None of them knew how to code, so they specced up a prototype and engaged
a web-development agency to build this MVP. Development was slower than
hoped for, and the specs changed repeatedly, based on the evolving strategies of
the founders and conversations they had with the big players in the industry.
Almost 10 months later, this MVP was ready for a trial launch. Unfortunately,
the product by this stage was so complex that it was almost impossible to use.
Successful use of the product involved no fewer than 14-stages, involving 3-way
communication between the bidder, the project-owners and referrals from
previous projects.
Theyd spent so long story-boarding their product that they had a really good
idea of how it would work once theyd achieved huge market penetration.
According to their vision, all communication would be managed within the
app, as everyone in the industry would be using it.
They had some pretty great features that were novel for the industry at the time sharing quotes electronically (step 8), exchanging & signing contracts online
(step 11) and eventually paying for the services (step 13) as part of the process.
Unfortunately, it was impossible to use an individual component without
completing all of the previous steps. Until theyd reached huge penetration
amongst all 3 types of user, their product would be almost unusable.
But, when looking back on the project, each of them professed that they thought
they were building an MVP.
The mistake they made was focussing too much on their vision or strategy,
and not enough on the dirty, mundane work of making a product that addressed
real needs or desires. Chances are that one or two of the 14 features were
genuinely useful and would have made a fantastic starting point for a startup.
Unfortunately, they were unable to work out which ones they were.

Unless people are incredibly lucky, theyre often not making something people
want.
Ideas for startups are worth something but mainly as starting points
An idea for a startup is only a beginning. A lot of would-be startup founders
think the key to the whole process is the initial idea, and from that point all you
have to do is execute. Venture capitalists know better. If you go to VC firms with
a brilliant idea that youll tell them about if they sign a nondisclosure agreement,
most will tell you to get lost. That shows how much a mere idea is worth. The
market price is less than the inconvenience of signing an NDA.- Paul Graham,
How to Start a Startup
Making something people want is not the product or conclusion of your idea
plus development time. Its not the end result - its the process. Making
something people want means prototyping, launching early (often by faking
large parts of your service) and talking to users.
Its the fastest, most cost-effective way of finding that smallest quantum of
utility - the kernel of an idea that solves a burning problem for a tiny subset of
people.
In other words, its a way of ensuring youre not wasting your time.
People
There are two kinds of people who most commonly have this problem.
The first is the Business Strategist. Hes the ideas guy who goes to meetups
to tell people about his gleaming vision for his startup. Hes a management
consultant, a banker, a lawyer. He doesnt want to get his hands dirty with actual
customers, and hes looking for developers to build his MVP.
The other is the Technical Purist. Hes often got a Computer Science Degree
(or several), hes a fantastic developer and hes worked at a big tech company or
in a well-respected development agency. He develops against the nightly builds
of the hottest new graph databases. Everything is test-driven and built to scale to
tens of millions of users. He loves building stuff so much that he doesnt want to
waste any of his time actually talking to people or selling his product.
At my company, GoCardless, we had a combination of both of these problems.
During the summer of 2011, we were 6 months into our startup. Wed built a
product the previous January and launched after just 3 weeks of development.

Our vision was to solve group payments - we were a platform for sports teams
& university societies to organise & collect money. We managed to convince
about 20 or 30 of our friends & family to collect money for their various causes from rowing clubs to stag parties. It worked ok - people we knew used the
product, and some used it repeatedly. It was enough to show a glimmer of
possibility, and it helped us get onto Y Combinator that summer.
By June, growth was stagnant. We spoke to our users every day, asked them
what additional features they wanted to see, and then we built them. From
scratch, we built a set of customisable forms for collecting information from
group members (wufuu, anyone?), advanced calendaring and reminder functions
(doodle.com) and the most complex set of functionality for managing large
sports clubs with multiple teams, roles and permissions that anyone could
possibly imagine. Our solution to crappy growth was to split out time roughly
50:50 between building more features and debating the vision of our company.
After an afternoon of meetings with pg & the other Y Combinator founders, we
resolved to take a different approach. Wed give ourselves 2 weeks to see if we
could make this thing work. We paused development entirely and spent all of our
time cold-calling new potential customers. And since our payments platform was
UK-only, this meant getting up at 3am East-Coast time.
One particularly memorable conversation involved 20 minutes speaking to a man
who ran a local village cricket club in the South-West of England. Id empathised
with the strains of running a sports club (Id run one at university), and the
terrible administrative burden it came with. Wed discussed the trials of
collecting subscription fees and the social anxiety caused by chasing up over-due
debts. So I moved to close him; Weve built a website to solve all of these
problems - give me your email address and you can try it out.
What, he asked, is an email address good for? Why would I have one of
those?
To communicate online, I spluttered, to use the internet!
The internet? I dont use the internet. Goodbye, sir he concluded.
Our problem, we discovered, was two-fold. One, that the mass-market didnt
appear ready for our product. It turned out that the most successful Irish sportsteam management tool (teamer.net) is still based almost entirely on SMS. The
second problem was more fundamental; we hadnt really discovered our
quantum of utility. We didnt have that tiny kernel of a product that solved a

really burning problem. Collecting money for sports teams is annoying, but its
only a small part of a few peoples lives.
On the other hand, it turned out that businesses faced the problem of collecting
money every day. And for particular people within those businesses - the
accounts receivable department - this was their entire job. The core of our
product - a Direct Debit API - was an ideal solution to this burning problem.
In nearly every failed startup, the real problem was that customers didnt want
the product The only way to make something customers want is to get a
prototype in front of them and refine it based on their reactions. - Paul
Graham, How to Start a Startup
To that quote I would add and if it turns out that no-one cares, do something
else
Most startups arent competing with other startups; theyre competing with no
one giving a shit.
A few years later
One of the founders of the construction startup (mentioned at the start of this
article) came across another group of founders who looked like they were on the
same path. This company had what seemed like a promising idea - an interesting
take on loyalty-schemes & subscriptions for real-world products and services. Its
non-technical founders were looking for a designer and a coder to build an iOS
app & website, which would be their MVP. Theyd planned out exactly how it
would work when theyd achieved massive adoption.
They had a long and frank discussion with the earlier founder. Heeding the words
of warning, this company reformulated its plans. What was the bare minimum
they needed to work out whether customers & businesses were interested? How
could they simulate the benefits of their service without blowing tens of
thousands of pounds on outsourced development?
The founders decided to sell shop-by-shop in their local area, signing businesses
up to their new platform, promising them new patrons & more repeat custom.
They then quickly ran a local advertising campaign offering people great deals at
their favourite cafes & bars. Instead of spending time & money building an app
and a website, they simply distributed laminated cards printed with with unique
IDs to their customers, and every morning took a paper lists to the local
businesses with details of the discounts each person was entitled to. Every night,
theyd collect the lists and manually enter the data back into an Excel

spreadsheet. By the end of the month, the majority of the businesses reported
remarkable increases in volume & cash-flow, in some cases up to 75%
improvement. They used this proof to secure investment & build a team of
developers and salespeople.
Conclusions
You should spend most of your time focussing on making something people
want. This is a process, not a goal.
If youre worried youre not making something people want, the solution is
almost always the same - focus on what youre shipping in the next month. Dont
obsess over long-term strategy, or stick dogmatically to a vision. Launch
sooner than makes you comfortable. Fake as much of the service or product as
you can to save time. Talk to your users to make sure youre solving a burning
problem. Once you have 20 or 30 regular users, do everything in your power to
absolutely delight them.
Ensure youre making something people want. If youre worried about this, ask
them.
Discuss this post on Hacker News

Advice
Starting a company is a challenging process - youre thrown into the deep-end
with nothing but your wits to help you. Often, though, advice will be
forthcoming. This post is about that advice, and how to spot the difference
between good and bad.
Some advice is expert - your lawyer talking about your Ts & Cs, or a sysadmin
giving advice on web-service redundancy. In these cases, youd do well to trust
the persons professional judgement and follow their advice.
Other advice is not.
Some people, as part of their jobs, are trained to give substantive, concrete, and
often completely baseless advice. In my previous life as a Management
Consultant, wed routinely give advice like sell these 400 under-performing
stores. There is a certain reassurance in the tangible, solid nature of the advice;
Do this and youll be fine. It absolves the recipients from spending more time
thinking about the problem - the experts had provided a solution. As long as the
advice wasnt demonstrably wrong, everyone was happy.
Unfortunately, early-stage companies arent like this. If you waste 3 or 4 months
misguidedly pursuing some market segment, or building a feature-set before
youve determined that youre really on to something, youll bankrupt your
company.
This is why advising early-stage startups is so fraught with difficulty - experts
from fields like law & accounting give substantive advice without really
understanding the nuance of the market or the product. In fact, almost no-one
else in the world is close enough to your customers to really understand their
problems. These are the problems that you, as a startup founder, should be trying
to identify & solve.
When my startup, GoCardless, was in Y Combinator, the advice we got was
different. Despite having some of the best collective experience in early-stage
startups on the planet, it was striking how rarely the partners would give this kind
of substantive advice. Instead, they dealt in mantras & heuristics. At the time,
this was incredibly frustrating - we wanted someone wise just to tell us what to
do. It apparently doesnt work like that.
Instead, they presented a set of rules which appear to maximise (but not
guarantee) a startups chances of survival:

Launch early & talk to your users (or, more completely Build the absolute smallest
thing that can be considered a complete application and ship it )
Make Something People Want"
"Dont Worry about Competitors
Focus 90% of your time on solving your one biggest problem
Dont Talk To Investors (until demo-day)
Be a cockroach (or Assume you wont get money, and if someone does offer you
any, assume youll never get any more.)

Sam Altman recently published a list of these at

http://blog.samaltman.com/startup-advice
When people come to you with a problem, its always tempting to give
substantive advice. This must be even truer for the Y Combinator partners - these
are people whove built & sold a number of highly successful businesses over the
last 15 years. Yet, by and large, they refrain. In retrospect, I find that a really
interesting phenomenon.
On the other hand, its troubling to see accelerators, especially in Europe, touting
their vast networks of mentors. Experienced accountants give great tax advice,
but dreadful startup advice. When it comes to acquiring your first 100 users, Id
stick with the mantras - Launch early, talk to your users & make something
people want.

Startup Series Part 1: Interviewing Engineers

Theres been a huge volume of literature written on the subject of startup
methodologies and philosophies. This is a positive thing for the ecosystem - just
as new software tools mean its simpler and cheaper to start a company, these
methodologies allow first-time entrepreneurs to avoid many of the pitfalls of the
past.
But Id like to write a more practical guide - what happens once youve launched
your MVP, iterated to a product that people actually want, and raised VC money
to scale? What are the day-to-day challenges youll face and pitfalls youll
encounter? Over the last 3 years at GoCardless, weve run into and subsequently
dug ourselves out of many of these pitfalls. By making these mistakes, weve
developed solutions that, at times, have dramatically increased our productivity.

Startup Series Part 1: Interviewing Engineers

The hiring process at technology companies has been the subject of a great
number of blog posts, often written from the perspective of disgruntled
candidates. They rail against what they see as capricious and ineffective
techniques. This problem will probably exist as long as interviews
produce unsuccessful candidates, but it is possible to design & run a process that
will annoy a very minimal number of people, whilst selecting the best of the
bunch to work at your company.
Once you have a good number of capable people applying to work at your
company (a much harder problem!), selecting the best of them should not be a
terribly difficult problem.
Over the last 3 years, weve seen around a thousand CVs, conducted hundreds of
interviews, reviewed several dozen coding challenges and ultimately made 15
technical hires. As a result, we identified a number pitfalls in the interviewing
and selection process. Usually we did this by stumbling into them head-first.

Define a process and stick to it

If youre not absolutely clear on what each step of the interview process
involves, and what youre looking for at each stage, youll inevitably resort to
weak, fluffy questions that dont really reveal anything about candidate. If you
throw a couple of your developers into an interview with no preparation, youve

wasted 2 hours of engineering time at best. At worst, youve alienated the

candidate and irritated your developers.
Instead, invest a little time defining what systems and processes youll use. Write
down this process and share it with your team and candidates. You dont need to
invent this from scratch - choose someone elses and adapt it to your needs.
Get an applicant-tracking system that stores CVs and the result of each interview
(with detailed notes), so that you can compare candidates based on data. If you
see a dozen developers in a week day, youre unlikely to remember each of them
by Friday.
Our process was pretty simple: CV screen, 15-minute phone screen, 2-hour
coding exercise, 1 in-person interview to debrief on the coding exercise, 2
subsequent final-round interviews, with a mix of technical and fit questions.
Ultimately, the output of each stage should be hire or no-hire. Rack up
enough hire votes from the different interviews, and you can make an informed
decision. If you want, you can assign a more granular score, but it rarely yields a
different outcome.
If you find yourself coming out of an interview and not being able to offer a
hire/no-hire opinion, youre asking the wrong questions.

Lack of preparation is unforgivable

Before the interview, write a list of good questions for each aspect of a
developers skillset - with a backend developer, for example, you might want to
focus on web technology, databases, system design and architecture and
algorithms. If you have 2 in-person interviews, split the topics between them
so that you dont end up covering the same ground.
You can do the same thing for cultural & personality interviews, but you need to
take care to avoid weak questions which either dont reveal anything. Often,
questions like why do you want to work at a startup? and why do you want to
work at this company? are just an opportunity for the candidate to blow smoke
up your arse. Its a vanity exercise.
Instead, I like questions like which parts of your previous job did you most
enjoy? Which parts would you avoid in future?. If you really probe for specific
examples, it can tell you a lot about a persons personality and motivations.

This list of questions should be shared with the company, and improved over
time. Id suggest its a key part of the companys IP.

Relevant coding challenges are the best indicator of ability

In my experience, relevant, realistic coding challenges are by far the best
indicator of ability. They should take roughly 2 hours, to be done in the
candidates own time, and they should tell you:
- at a basic level, can the candidate structure a simple system?
- does the candidate write fluent, idiomatic code, in the context of whatever
language is chosen?
- can the candidate select & use appropriate libraries?
- how much effort has gone into building the system?
For example, we sometimes ask people to write a client library for a real-world
API or web-service in a language of their choice. I really like the exercise
because there are such a range of solutions and opportunities for people to
demonstrate exceptional ability and effort. There are also a number of great
extension questions when you ask the candidate to talk you through the solution.
How would you speed-up the client or the API? What are the different
approaches to caching? How might you fetch a great number records
simultaneously? If you were maintaining the API, how would you deal with very
high volumes of requests? What are the various ways of dealing with API
versioning?
We also tend to do some fairly lightweight algorithmic coding challenges in
person - calculate row n of Pascals triangle or implement a basic sorting
algorithm, for example. Its important to provide a clear definition of the
algorithm in question, allow the candidate use of a language of their choice and
their own development environment, otherwise youre not testing the right
things. Interestingly, the optimal solution to many of these challenges involve
recursion - a technique that seems to baffle some developers.
These shorter tests tend to reveal whether people can think under pressure,
communicate clearly and debug broken code in a sensible way. For example,
faced with a half-working sorting algorithm, a bad candidate will start changing
variables at random. A good candidate would work methodically through the
problem, ideally adding debugging lines that output the values of relevant

variables at each stage. Its worth noting that, while useful, these tests are not as
good an indicator of on-the-job capability as the longer coding challenge. Many
fantastic engineers dont excel under this kind of high-pressure situation, and
actually its not the kind of scenario theyd encounter on-the-job very often.
At the other end of the spectrum, asking someone to complete a 3 or 4-day
project might be the ideal way to judge aptitude, but it just isnt realistic in our
experience.
Practical Tips
Finally, there are a number of simple practical tips that will make your life much
easier:
Wherever possible, try to bunch your interviews into blocks of time. At the most
extreme, I met 8 applicants for in-person interviews in a single day. Its
exhausting, but it avoids constant distraction and context-switching, and allows
you compare candidates more effectively.
Have one person in the company who is responsible for receiving & screening
CVs. Do this in blocks of time, once or twice a week. Otherwise, it can get
overwhelming
Be clear what youre looking for from CV- and phone-screens. You could
be wasting a lot of time. Write a checklist after youve seen a dozen or two CVs.
We should have rejected way more people at this stage.
Whatever the outcome, respond to candidates quickly and constructively. It
makes them feel valued, and its simple good manners.
Finally
Even using this process, youll make bad hires. It happens, and its not the end of
the world. Fire fast and move on. Overwhelmingly, the bad hires we made were
due to poor preparation, or, at times, wilfully skipping most of this process.
Hiring well is one of the most important things you can do for your company.
Dont neglect it!

Id love to hear your thoughts - please comment below, or follow the discussion
over at Hacker News

Startup Series Part 2: Attracting great engineers

This is the second in a series of articles on the operational side of running startup
- once youve found product-market fit and raised VC cash, how do you go about
building a business?
The first post in this series, on the hiring process, assumes you have a sufficient
number of quality applicants. Once thats true, hiring becomes a process
optimisation problem - it might take a bit of effort to get right, but there arent
too many unknowns. On the other hand, attracting top-quality developers to your
company in the first place is a much tougher proposition.
In the long-term, you will attract outstanding talent if you;

build a successful company with a strong vision

working on interesting technical challenges
with other outstanding developers
who value software development as a professional trade.

The often-omitted final step is to tell people about it! You could have the best
culture in the world, but you wont attract applicants if no-one knows about you.
Github is one of the best in the business when it comes to attracting great talent.
People like Zach Holman and Tom Preston-Warner blog profusely and tour the
world talking about software development. But, underlying every article and
presentation is this message; Github is an awesome place to work.
Since not every company can spend hundreds of thousands a year flying people
around the world for conferences, or fit their reception area out as a replica of the
Oval Office, I wanted to share a few actionable tips for the first-time
founder. These shorter-term fixes will provide value disproportionate to their
cost. There are also a few gotchas - common practices that do more harm than
good.
Provide top-quality equipment
Dollar-for-dollar, high-quality equipment was consistently the most sought-after
perk when weve surveyed developers, above a swanky office, fancy snacks, and
even salary. It makes sense to invest here.
Some simple maths backs this up - depending on experience, you might pay
anywhere from 30,000 to 70,000+ for a software developer in somewhere like
London. Upgrading from a standard MacBook air to top-of the range model plus
Thunderbolt display will cost you an additional 1,500. Youd need to achieve a

1.9% productivity gain (based on a 40k salary and a 2-year equipment lifetime)
to pay back the investment. If this equipment reduces the running time of your
test-suite by two minutes, youd save about 4 days a year[1] which, alone, is
worth about 1.8% productivity boost.
[1] 4 days = 2 minutes * 5 runs a day * 225 working days per year
It then costs, conservatively, 5,000 to attract and hire a single developer. If topquality equipment has any impact on hiring or retention, youve suddenly made a
profitable investment. You also get to take lots of cool photos of your working
environment and post them all over twitter and your hiring page - remember that
telling people is the most important part.

Interesting observation; while we still let people choose their equipment, we

strongly encourage people to choose between the MacBook Pro and Air. Weve
had several people originally opt for various flavours of Linux, but theyve all
swapped over to Macs within 12 months. The homogeneity means that
equipment will work anywhere in the office - swapping desks to work with a new
project team simply means plugging into a new Thunderbolt, rather than lugging
tonnes of equipment around. It also means that useful internal tools & scripts that
weve developed are more likely to work out-of-the-box.
Work on awesome side-projects

Weve found that having the engineering team take a couple of days off work to
hack on a fun side-project can be a great recruitment tool. Not only does it
increase morale and let you try out new technologies, it also provides you with
great content for blogging & conference talks.
The best example is our pool-ball tracker we built at GoCardless. We mounted a
webcam above our office pool table, and used OpenCV libraries to track the
position of the balls. The ball coordinates were fed into a rules engine which then
scored the game. It got a great reception on Hacker News and elsewhere, and
resulted in an extra 9,000 unique visitors to our site on a single day. And it was
awesome fun.
Other examples are our GoCardless-branded beer and Raspberry Pi projects.
Our only failure here was a Spotify-powered office music system - we just never
got around to blogging about it. As with everything on this list, its only effective
if you tell people about it.
Technical & Culture Blogging
This is the single greatest recruitment tool weve found. If youre using any kind
of technology at all, or have views on development best-practices and startup
culture, you should be able to write compelling content that will do well on
places like Hacker News and Reddit. Its also more more repeatable and has a
higher ROI than side-projects, because it doesnt require half-a-dozen people to
take multiple days off work.
For example, one particularly incendiary article on ditching Responsive Web
Design garnered 34,000 unique visitors on a single day. Weve had several
applicants explicitly mention this article during interviews, even 9 months down
the line.
You can blog about pretty much anything you work on - meetings, org structure,
a new javascript framework youre using. Explaining how youre different from
just another BigCo is an extremely useful recruitment tool.
Often, the key to getting traction on somewhere like Hacker News is choosing a
punchy title and taking a slightly more extreme position (See Hours are
Bullshit) that you might otherwise do. Interesting technical posts do well, too.
From a practical point of view, make sure you host the blog on your companys
domain (SEO benefits), mention your companys name and link to your hiring
page in an inoffensive way.

Open-source your tools

As a technology startup, youll be successful if youre closer to your market &
customers than your competitors, and youre able to respond more quickly to
their needs. As such, giving away tools that make you more productive initially
seems counter-intuitive, but its not. Depending on your market, your
competitors are likely to be slow-moving incumbents. If theyre still struggling
with Visual Basic .Net and SOAP APIs, releasing a new Ruby deployment tool
isnt going to help them much.
Even if thats not the case, open-sourcing useful little tools will dramatically help
your recruitment processes - Github are the authors of the well-known Ruby
tool Resque, for example.
At GoCardless, weve not been as good as wed like at open-sourcing our tools,
but thats changing. Weve just released Hutch, a Ruby tool for RabbitMQ, and
some development widgets for Dashing. Next on the list is a neat little tool
written in Go that makes it simple to spin up multiple services in a local
development environment.
When you open-source your tools, dont forget to tell people about it! At the very
least, its a nice thing to do for the ecosystem.
Speak at meetups & conferences
This is really an extension of the previous three points - take all the great content
youve produced from your fun side-projects and open-source contributions, and
package them up into neat 20-minute presentations with some interesting slides.
Its great for your engineers personal development, and it really helps spread
your name around the relevant communities. You dont need to spend a lot of
money on flights around the world, either. Many cities have very vibrant usergroups which hold meetups every few weeks - theres an Angular JS group in 50
cities around the world, for example.
Encourage all of your engineers to attend - and make sure youre wearing your
company t-shirts! Its a great opportunity to talk to other like-minded developers
about the interesting technology youre using.

Finally

These are five pretty simple things you can do to increase the number of quality
applicants. The most important factor is simply to get your name out into
whichever community youre trying to recruit from. If you spend a couple of
weeks building a cool new tool, don't forget to spend the final hour or two
writing a blog post about it.
Id love to hear about other tips people have - you can follow the discussion over
at Hacker News

Startup Series Part 3: You make what you measure

Merely measuring something has an uncanny tendency to improve it. If you want
to make your user numbers go up, put a big piece of paper on your wall and
every day plot the number of users. Youll be delighted when it goes up and
disappointed when it goes down. Pretty soon youll start noticing what makes the
number go up, and youll start to do more of that. Corollary: be careful what you
measure.
- Paul Graham
Metrics are one of the most powerful and most dangerous tools at a startups
disposal. They can help focus a team around a common goal or push you offcourse for months.
Start by tracking one thing
We realised pretty early at GoCardless that we needed to track something to
work out if we were improving. As we are a payments processor, the first metric
we chose was our total daily transaction value - how much money was going
through the system. We chose this metric because, in the very early days, total
daily transaction fees (ie our revenue) was embarrassingly low, whereas our total
transactions were roughly 100x higher. This worked well for a few months - we
hit milestones in encouragingly quick succession, moving from 1k-a-month to
1m-a-month to 1m-a-day. Wed display the daily number on a large board in
the office, and send weekly and monthly summaries to everyone in the company,
with the change over the previous period. It worked well both to motivate the
team and act as a Pole Star when making decisions; which of these options will
maximise our monthly transaction value?. When we hit 10% week-on-week
growth, we were happy. When we didnt, we redoubled our efforts.
Choose a proxy for long-term value
However, a year or so down the line, we realised that wed encouraged some
pretty perverse behaviour. A large minority of our transaction value was coming
from a few merchants putting through very high-value transactions. Because of a
quirk in our pricing model (1% capped at 2 per transaction), we were actually
making relatively little revenue and assuming way more risk than wed like on
these customers. For a short time, we were actively pursuing more of these
customers in order to boost transaction value. Yet, when we came to search for a
solution, it was incredible how ingrained our hunt for transaction volume had
become - any change we made to combat the problem would inevitably result in
lower transaction values, although dramatically higher revenue - and yet,

emotionally, we struggled to make the change. Once we swapped the key metric
to daily transaction fees, the problem went away.
Since it sometimes seems fashionable to run companies without revenue, you
need to pick the best proxy for long-term value of your company, be that profit,
revenue, installs, MAU or page-views. But this raises the next problem we
encountered. Even if you could track company value on a day-to-day basis (and
you can if youve gone public), its not an actionable metric. This is usually a
problem for B2B companies since the enterprise sales cycle can often be several
months - the work you do today wont impact revenue for some time.
Break out KPIs
One solution is to have each team within the company break down that key
number into its component drivers until you get to something actionable. A really
neat example is an outbound telesales team. Ultimately, you want your sales
team to be closing recurring deals, which will drive revenue in a predictable
fashion. But, as any sales director will tell you, if youre not closing the deals,
you need to focus on the activities youre performing. The stage before a closed
deal might be some form of proposal, outlining the key SLAs you will deliver in
return for committed fees. To deliver 5 closed deals this month, you might need
to make 10 proposals. To make those 10 proposals, you need to attend pitch
meetings with 20 companies. To get those pitch meetings, youll need to have
spoken to 200 companies. Since only 1-in-3 cold-calls results in a conversation
with a decision-maker, your telesales teams need to call 600 companies this
month. Suddenly, you have some pretty actionable KPIs for your sales team.
These are the numbers that you track in daily stand-ups, and measure conversion
between each stage. Since they are actionable metrics, the entire process becomes
an optimisation problem.
As far as possible, each part of your business should have 2 or 3 actionable
metrics that they examine on a daily or weekly basis. Theyre the numbers that
tell you whether youre improving or not. An example might be website up-time
for the devops team, or average customer wait-time for your customer support
team. Whatever numbers you choose need to be objective - if people can
massage up a bad month, it undermines everyones faith in the metric. These
metrics shouldnt be sticks to beat people with - its actually incredibly
motivating to work very hard and see that youre making progress. Theyre also
useful to highlight strategies or areas of the business that just arent working out,
rather than allocating personal blame.
Eric Ries spends a lot of time in the Lean Startup talking about actionable vs
vanity metrics - its well worth a read.

Implement your strategy with KPIs

The choice of KPIs is also a very powerful tool for a founder or management
team to set the direction of a company. There are many different ways to reach
1m in monthly revenue - the way you set up your KPIs and associated targets
will have a huge influence over the behaviour of people in your company. As a
simple example, are you aiming for 10,000 customers to pay you 100 each, or
100 wholl pay 10,000 each?
When metrics go wrong
Even these actionable KPIs can produce perverse behaviour. I worked at a large
national utilities supplier whose (very large) email customer service team
committed to responding to 90% of emails within 24 hours. On the face of it, a
great actionable metric - and the team were consistently replying to 89 or 90% of
emails within the allotted time. But theyd also developed a practice of simply
ignoring any email which exceed the 24-hour cutoff. Since these emails didnt
impact their targets (or their bonus), 10% of customers simply never got a
response.
A final issue is that, in some areas of your business, KPIs can be really tough or
even impossible to pin down. While a front-end team working on your landing
pages might measure conversion to signup, a PR team running a 6-month
campaign may struggle to find an objective indicator of success. You can try to
count the number of articles (and the readership of each), but youd also need to
assess the relevancy of the target audience. You might try to establish a baseline
of page-views and count increases or spikes, but theres so much noise that it
quickly becomes subjective. While people have tried to to pin down the value of
a like or a re-tweet, its only usually relevant for consumer-facing
companies. Weve never really managed to find a solution to this problem - Id
love to hear what other companies have done.
In summary

Pick one number thats your Pole star - the best proxy for long-term company
value. Re-examine it periodically to see if its producing perverse outcomes.
Have each team break down the key metric into its component drivers or KPIs that
individuals can influence. Measure team & individual performance & improvement
on this basis.
Make sure the numbers are objective.
Make them visible - put the key metric on a big dashboard, and give each team a
dashboard that lets them see how theyre doing. Send regular automated emails
around your teams with a breakdown of their numbers.

Follow the discussion over on Hacker News

Startup Series Part 4: Deadlines

The question of deadlines is one of the most divisive issues in software

development today. Business-people despair at developers inability to meet
goals, while developers lament the latest unachievable deadline imposed by their
pointy-haired boss.
In practice, there is often a common cause of this malaise. If your team doesnt
have an agreed scope with sufficiently granular time-estimates for each
component piece of work, your project will inevitably overrun, and sometimes by
an order of magnitude.
Scoping a project
The solution is to come up with a scoped deadline - a date in the future by which
you will have implemented an agreed list of features or functionality. Crucially,
each of the features needs an estimate of the amount of time or effort required to
complete it, similar to some styles of Agile software development.
The only effective way to estimate effort is to break the project down into chunks
of work that can individually be estimated. In no case should any chunk be more
than 2 developer-days, and ideally theyd be around a day each (4 hours).
There are lots of methods for actually coming up with these numbers - Planning
poker is one neat collaborative solution, or Joel Spolskys Evidence-Based
Estimation is also interesting.
Fundamentally, developers should be the people saying how long a given chunk
of work will take. Whatever system you use, its essential to have a relationship
where developers feel like their judgment is respected and the business-side of
the company trusts developers to put in a reasonable amount of effort. At the end
of the day, even the best estimation techniques cant fix a broken culture.
The alternative, an its done when its done attitude, is dangerously
counterproductive - if theres no pressure to hit business goals, technical
decisions will tend towards feature-creep and perfectionism.
Why scoped-deadlines are useful
As far as I can see, there are 3 main benefits of scoped deadlines:
It makes you iterative - forcing everyone involved to ask is this feature really
necessary?. You will always have more development work than time available,

so choosing what to work on is a crucial skill. If you strive to keep your

deadlines around 2 weeks, you will prototype very quickly, building only the
features you really need. Half the time, customer feedback will change what you
saw as version 2 anyway.
Second, it prevents scope creep during the project, as youve locked-in the
features that are going to be delivered. This is good for both developers and
business-people. For the former, it encourages a pragmatic approach to the
quality-vs-speed tradeoff - personally, it helps me check the urge to refactor code
when it isnt strictly necessary. For the latter, it provides a positive response to
the perennial request of can you just implement XYZ for me?. Sure - in the
next version.
Third, it can sometimes good for motivation & productivity, for some
combination of people, teams & problems. I find deadlines energising - crossing
to-do items of a list, and delivering impressive new feature motivates me. Its a
very tangible way for a team to see that theyre making progress, and people love
being part of success. But its certainly the least important of the three.
Deadlines in practice
As a project progresses, you should be regularly deploying your code - use a
feature-switch to keep new work visible to only staff or small segments of your
user base. This is very important because its a leading indicator of missed
deadlines. If youre halfway through your sprint, and no code has been
deployed, youre likely going to overrun. It also helps catch bugs early, and
makes you consider how your code will interact with the existing codebase from
the very start.
Even with this advice, you sometimes just wont hit your deadlines. It might turn
out that the version on open-source library youre using isnt compatible with a
new tool you want to implement. Unexpected problems crop up. While I dont
think its a terrible thing to work a couple of late nights if your project needs to
get back on track, its very different if the scope of the project has fundamentally
changed.
Retrospectives are a good way to identify any patterns in scoping problems - if
you highlight areas that consistently overran, youll get better at spotting them in
future.
On the other hand, be quick to celebrate your successes. Releasing code from
behind a feature-switch to your general user-base is a great time to gather the
team and reflect on your achievements.

Discuss this post over at Hacker News

Growth
When eating an elephant, take one bite at a time.
- Creighton Abrams
I was chatting with an investor a year or two ago, shortly after our Series A, and
the subject of revenue goals came up.
At the time, our revenue was pretty low - less than 10% of monthly costs. We
estimated our business would only become viable when revenue reached a level
10 times greater than our current costs.
The implication was that we needed grow by 100 X before our business had any
significance at all, and I was struggling to come up with any credible plan for
getting there.
Her response was for us to simply put one foot in front of the other. Just focus on
growing every month, and the rest will take care of itself.
At 15% month-over-month growth, youd grow by 100 X in around 33 months.
At 20% month-over-month, it takes 25 months.
At 25% month-over-month, it takes 21 months.

Customer churn can kill your startup

Startups are about growth, and of all the different possible metrics, startups often
focus on user growth - if people arent using your new product or service in
greater and greater numbers, its a good sign that youre not on the right track.
And, as long as your business-model is solid, user growth is a leading indicator
of revenue and profit growth.
But theres another key metric that can be the making of your company, or the
death of it - churn, or the proportion of existing customers who become excustomers during a period of time (generally a year).
In the early days, its very hard to measure your churn because you simply
havent been around long enough. The early revenue growth curves for high- and
low-churn companies may look identical.
In fact, high-churn businesses often have exceptionally impressive growth
numbers in their first months or years because theyve found some viral loop, the
crack cocaine of startup-land, which provides an explosive catalyst for new-user
acquisition.
However, problems often start to appear after the first year or so - occasional
weak months look exceptionally bad, since your business model relies on new
customers in the top of the funnel to replace those flooding out. And even if you
manage to keep finding new people to push into the top of your funnel for several
years, you will eventually churn through your entire addressable market.
Then your business implodes.
The prime examples are Zynga and Groupon - both of which have been
catastrophically failing over the last year or two.
Conversely, low-churn businesses often have relatively modest initial useracquisition growth curves. Often, the nature of low-churn businesses (in
particular, high switching costs) makes it incredibly hard to gain your first few
users before youve established credibility. However, these same hurdles present
considerable long-term advantages, and the occasional slow month in terms of
user-acquisition still increases monthly revenue. Once youve built up a loyal
customer base, it becomes an extremely attractive business model - costs are
often fixed & up-front, and the marginal cost to serve each customer every month
is minimal.

When talking to startups, my favourite graph to look at is their revenue by

monthly cohort. That is, splitting each months revenue by the month in which
the users originally signed up to the service.
In a low-churn business, the graph looks like a layer-cake, with each new month
of users adding a layer of revenue on the top of the business.

The thin cohorts at the bottom of the graph are the loyal users who signed up at
the start, and who are still paying for your service 18 months later. The orange tip
in the top-right are the users who just signed up, and have only contributed to
revenue in month 18.
In the best low-churn businesses, the revenue provided by each cohort can
actually grow over time - each cohort gets fatter - if you can successfully upsell new services.
In a high-churn business, the cohorts decay alarmingly quickly, and once newuser acquisition starts to slow, the business implodes.

If you simply looked at the top-line of the graph (total monthly revenue), without
considering the cohorts, youd think the high-churn business was doing much
better until at least month 13-14. But one-and-a-half years in, its clear that the
low-churn business is on a path to success, while the high-churn business needs
to execute a substantial pivot to avoid failure.
Indicators of Churn
So what are the characteristics of high- and low-churn businesses, and what
techniques can you use to minimise churn?
High Switching Costs - if its slow, painful & costly to switch providers, you
will experience very low customer churn. This is clearly the case with retail
banks, email providers and recurring payment processors. I still bank with the
same provider I chose 15 years ago, despite their crappy service and barelyfunctional website.
New competitors have developed clever tactics to solve this problem developing onboarding tools to reduce switching costs, or focussing on new
customers before theyve committed to an incumbent provider. This is one
reason Stripe focusses so hard on serving other startups, and banks target
teenagers.
Sales Architecture - the way a product is priced & sold is often designed to
minimise churn. Gyms & dating sites are the best examples here. People come
out of the Christmas & New Year vacation period feeling unhealthy, lonely, and
determined to change. One large dating site books over 70% of its annual
revenue in the first quarter of the year.

Strong Brand Loyalty / Personality - the best brands position themselves as

expressions of their customers personality.
Cigarette companies and beverage manufacturers are the best example of this products are often indistinguishable from each other, and the switching costs are
minimal. The customer can just reach for a different can on the shelf. Companies
combat this by investing heavily in marketing to position their products in
customers mind as extensions of themselves.
Theres an interesting phenomenon in the drinks industry where a couple of
faceless mega-corps control a wide variety of incredibly powerful brands with
basically indistinguishable underlying products - MillerCoors and Anheuser
Busch.
Make Something People Love - after some fantastic comments from readers,
Ive added this extra point. Perhaps the most difficult, but also most effective
form of customer retention is making a product or service that is dramatically
superior to the competition. As Barry put it, The switching cost is missing out
on a great service. Its subtly different from brand loyalty - Google has very low
churn because its search engine is so much better than the competition. It
arguably doesnt have a very strong brand or personality.
So What?
To some extent, youre stuck with the churn inherent in your industry. But you
do have some level of control.
If you enter a market like payment processing, be prepared for the long-haul.
Youll likely struggle to establish your credibility early-on, and finding
innovative ways to acquire new customers be vital. Youll need to raise
significant amounts of early capital to invest in infrastructure that will only start
to pay off years later.
If youre part of an industry in which you can acquire customers incredibly
cheaply and monetise them quickly, youll generally need less early capital.
Youll often reach profitability very early on, and it may feel like youre on a
startup rocket-ship. But make sure youre providing sustainable, long-term value
to your customers, otherwise you risk running out of fuel and crashing painfully
back to earth.
Discuss this post on Hacker News

Apple is propping up a fundamentally broken payments industry

Apples latest announcement on payments has sparked some interesting debate
but also a fair share of breathless pronouncements on a revolution" in mobile
payments.
To be clear - Apple Pay is a step forward in terms of end user experience - but it
simply entrenches a fundamentally broken card payment network and layers on
even more cost.
Apple have long been masters of user experience - and Apple Pay does makes
significant strides forward in that area. The point-of-sale experience is good, but
not much better than contactless cards that have been common in Europe for
years. The real leap forwards is in-app payments - new apps installed on an
iPhone will have access to payment details without the user having to type in
card details for every new purchase. Instead, customers will be prompted to scan
a fingerprint, and the payment will be processed - thats a pretty big leap forward
in terms of experience.
Theres been speculation that this new payment mechanism might lead to the
virtualization of credit cards. But what does that really mean? Apple is not killing
the credit card. Theyre killing the little piece of plastic that gets sent in the mail.
Again, a big user experience improvement, but a trivial improvement at the
payments level - payments are still going across the card networks.
Fundamentally, having to switch out a card to access a different credit product
seems wrong-headed.
All this talk of frictionless credit cards presupposes that cards and card
networks are necessary in the first place. Perhaps a more interesting question is
"frictionless credit.
To understand how this might work, we need to break down a payment
transaction to see where credit fits in:

A customer presents a card to merchant for payment, perhaps entering a PIN in a

terminal.
The terminal sends transaction details up a line from the merchant to a payment
processor.
The processor forwards transaction details to the card companys network.
The card company routes transaction details to card issuer (the customers bank, or
an independent financing company) for authorization. Is there credit available? Ie, is
customer within agreed balance or overdraft limits?
Issuer approves transaction and sends confirmation back through same channels.
The customer gets their item from the shop and leaves.

The credit in credit card is not related to the plastic card, or even the card
network. Its simply debt financing thats offered by a financial institution at the
other end of a series of pipes. Visa & co provide those pipes, but charge a pretty
heft fee for doing so. Thanks to the existing 4-party system, merchants are paying
around 2-3% of every transaction as a tax levied by those incumbents, who add
little value in return. Apple now makes that a 5-party system, adding extra cost in
exchange for a slick user experience.
With Apple Pay, instead of a user inserting a card and entering a pin, theyd
present their iPhone and touch their thumb to a fingerprint reader. Their iPhone
passes up credit card details via the card processor (or, more precisely, it passes
up a token that allows the card networks to access card details from Apples
servers a little way down the line), and the process continues as normal. The
metaphor of Apple Pay as a simple wallet works well - it simply provides a
mechanism for storing your cards, and presenting them to merchants when you
want to pay. They arent actually processing any payments themselves., unlike
PayPal or Google Wallet.
Apple Pay entrenches a fundamentally broken card payment network, and layers
on even more cost. Apple has struck deals with Payment Networks and Issuing
banks, and as part of those deals, it is taking a cut of the fee. Its now another
mouth to feed.
What we should be aiming at is frictionless payment over a different series of
pipes - the public internet, and existing inter-bank electronic clearing systems. If
Banks opened up their platforms to allow multiple credit providers, wed have
competition to offer consumers credit financing on competitive terms. Whether
you need an overdraft, a fixed-term loan or individual-item financing, you should
get the best rate available in the market. The idea of having to switch payment
card to get access to the best rates is crazy.
By decoupling the issue of credit is from "payment network, we expose the
card networks for the rent-seeking oligopoly they are.
Discuss this post on Hacker News

Getting Shit Done

I was recently talking to a handful of successful startups founders about issues
they were facing as they scaled up their companies. Unanimously, hiring and
retaining people who get shit done seemed to be their biggest problem. Ive
been thinking about this for the last few days, because its a deceptively simple
idea.
Its deceptively simple because people have a very strong cognitive bias practically everyone thinks they get shit done, much like everyone thinks they
are an above-average driver.
Empirically, most people do not get shit done.
So what does "getting shit done look like? How can you define it?
The closest Ive come is someone who, when confronted with a problem, will fix
it with a surprisingly good solution in a surprisingly short amount of time. They
have an ability to produce an astonishingly high quantity and quality of work.
Its someone I am confident giving my hardest, ugliest problems to, knowing that
theyll solve it better than I could. And when they present the solution, youll see
they found a bunch of other problems along the way and fixed them too.
These are the kind of people you should try to start companies with. If youre
already running a startup, they are your most valuable assets. Give them more
equity than your board is comfortable with, and try to get them to stick around as
long as possible.
In Paul Grahams formulation, they are relentlessly resourceful. Somehow,
they just seem to defeat any problem. There are many different strategies. You
can plough through an obstacle with brute force applied in just the right place. Or
you can avoid the obstacle by redefining the problem, changing the rules of the
game to suit yourself. Perhaps simply refusing to give up, and working harder
and longer than anyone would consider reasonable. And sometimes doing things
that look a little crazy from the outside.
The opposite is uncomfortably common. There are many people who will talk
about problems, strategise different solutions, seek input and group consensus,
but never actually accomplish anything. When things dont happen, they always
have a list of reasons why its not their fault. In a startup, this person needs
weeding out as quickly as possible because theyre dead weight.

Once a company is running, it can gain a momentum all of its own. This seems
especially true for big companies with a stable customer-base and market share.
Some large companies have such momentum that a large proportion of the
employees could simply not come to work and the thing would keep going all by
itself. Big companies seem to train managers to be interrupt-driven, rather than
proactive. So if youre hiring from big companies, watch out for this.
Consistently getting shit done takes a huge amount of energy and initiative, but
it seems energising for the right kind of person, rather than exhausting. It is a
particularly important skill in the early days, because the natural state of a startup
is inertia and, ultimately, failure. At first, your company has zero velocity, so you
need to apply an incredible amount of time and energy to overcome this inertia
and get the thing moving. Nothing happens unless you make it happen.
My favourite example is the story of Instacarts early launch with Trader Joes.
Instacart is a grocery delivery service and partners with some of the biggest
retailers in the world. But when they were starting out, they wanted all of the
inventory of Trader Joes listed on their site, along with the price and photo for
each item. A normal approach would have been to negotiate a business
development deal, which would have taken many months, killing momentum.
Instead, the founders figured out that they could probably purchase one of every
single item in the store, and working for 48 hours straight, photograph it all in a
studio that was empty over a weekend. In my book, that is getting shit done.

Five Unbreakable Rules for Startups

Ive been involved with 4 startups over the last 10 years or so, 3 as a co-founder.
Im a follower of Paul Graham and the YC camp of startup wisdom. Theres now
a great deal of literature laying out the unbreakable rules for startups. Despite
studying this literature, Ive managed to break each of these rules, in some cases
more than once. In every case, I have come to regret it.
1. Choose your cofounders carefully
If your startup is successful, youll spend the majority of your waking time with
these people for the next 5 years. Invest the right amount of time getting to know
each other. Ideally, youll have worked with these people for a few years at
another company before you do your own thing.
Your relationship will be like a marriage, but even more intense.
Three co-founders feels like the right number. Try to find the most driven,
effective people you know and convince them to join you. Unless theres a really
good reason, equity splits should be equal. If you dont think your cofounders as
effective or valuable as you, why are you starting a company with them?
2. Written agreements from the start
An agreement doesnt have to be complex, or necessarily involve lawyers. There
are plenty of open-source co-founder agreements published by law firms. But
you need to agree:
a) Any money invested, either as equity or debt
b) Equity split
c) Salaries, included any deferred compensation
In the simplest case, the agreement will be no money invested, equal equity
splits, zero salary. But as soon as bills need paying, things get trickier. An
investor friend recently told me that he makes a rule of telling founders, I wont
ask you to trust me. All deals go into writing immediately.
3. All stock must be on a vesting schedule
Vesting means that stock is earned over the lifetime of a persons involvement at
a company. A standard vesting schedule is 4 year vesting with a 1 year cliff.
This means, if I have 48 shares in a company, 12 of those become irrevocably
mine (i.e. vest) on the first anniversary of my joining the company. The

remaining 36 shares vest monthly over the remaining 3 years - 1 share per
month.
If I leave (or Im fired) after 3 years, I walk away with 36 shares. The remaining
12 shares are taken back by the company.
Vesting is a good thing for everyone. It ties peoples incentives to the long-term
success of the company. Ive heard founders even talking about 6 or 8 year
vesting sometimes.
If your co-founder says just trust me, see above.
4. Keep company money separate
When your company needs to pay bills and youve not raised outside investment
yet, be very clear whos paying and under what terms. Is the money going to be
repaid? When?
As soon as you can, establish a separate company bank account. All cofounders
ideally put the same amount of cash in, and bills get paid out from that account.
Simple.
If youre putting in money as a stop-gap before an investment round and expect
the money to be repaid, put this in writing. It should appear in your companys
balance sheet as a liability - Director Loan. Youll also need to let investors
know if you expect to use their investment to pay back loans.
5. When you go out to raise investment, dont over-optimise for valuation.
PG stood up one Tuesday evening at Y Combinator with a memorable lesson.
YC companies are competitive about everything. In each new batch, founders are
told not to compete over who can raise at the highest valuation. And every batch,
some founders ignore this advice. Airbnb, we were told, raised their seed round
of $600k on a valuation of something like $3.5m - certainly nothing like the
uncapped convertible notes we sometimes see at the moment. And the Airbnb
founders are just fine with how theyre doing.
You should spend a little time figuring out what price the market will offer.
Choose the investors you think you could work with for next 5-10 years. Dont
spend time shopping the deal around to increase your valuation. Also, dont pick
crappy investors just because they offer a higher valuation.
These rules are not negotiable!

If you break them, you will end up in trouble.

When to join a startup

Something has changed in the last few years which has made an increasing
number of people want to join startups. It seemed to start around the time the
Social Network movie came out - perhaps its just a coincidence, but part of me
imagines a group of MBAs sitting around watching Justin Timberlake play Sean
Parker, thinking that actually a billion dollars would be pretty cool.
When choosing a startup to work at, people often overlook one of the most
important factors, which is the size and stage of the company. Id argue this is
sometimes even more important than the industry or the idea itself.
Bootstrapping, aka two people in a bedroom
The startup was recently formed, and the company might not even be legally
incorporated yet. Theres no funding and no-one is taking any salary. Youre
two, three or four people in a bedroom living on baked beans, working all hours
of the day to get a working prototype to show to customers or investors. The only
people using your website or app are a couple of sympathetic friends and your
mum.
Someone else tried to convince you to join a different startup a year earlier, but
they had no funding and zero customers. They wanted you to work without a
salary in return for 1% of equity, which sounded like a scam to you. Youre glad
you picked this startup instead. You might not be getting any salary, but at least
youre joining as a co-founder with a double-digit equity stake. You jokingly talk
with your cofounders about which island youd each buy when you sell out for
billions in a few years time.
The product vision is vague and broad, but youre working every day to try to
validate it with customers. Anything is possible. The entire direction of the
company might even be changing from week to week.
Because nothing yet exists, you need to bring it to life with a combination of
energy and raw self-belief. Theres little specialisation and no hierarchy;
everyone does whatever needs to be done. It can be exhilarating.
It can also be exhausting at times, lasting months or years before you find
customer traction or funding.
Seed-Funded
Now the company has a working prototype, a few dozen regular users and 250k
of seed funding. Its enough to pay a handful of people low salaries. Since youre

too big to fit in a bedroom, youre renting desks at a coworking space or

scrounging them off a bigger startup.
You cut a lot of corners, but seem to ship an incredible amount of code. People
you dont know personally start to use your product and it feels awesome. Youre
working hard to spread the word, perhaps even starting to earn a little revenue
from your first paying users.
You join at this stage for 3% equity plus whatever basic salary you need to
survive. You talk about which cities youd buy houses in when the company
sells.
You might join as the first professional programmer or designer, but youre still
more-or-less on your own. When you join, your first job is to go to the Apple
Store and buy yourself a laptop because no-one thought to order any equipment.
Theres no mentorship from more experienced colleagues or even code-review,
simply because the company is still too small.
Marketing consists of one of the founders emailing your funding
announcement to TechCrunch
As an employee, you have a significant say in the direction of the company,
although the business model might still shift substantially underneath you. Even
if youre not making the decisions, you hear about them immediately.
Theres still a good chance that the company fails to find product-market fit
and goes bankrupt without raising more money. Your mum tells you that you
should have stuck with your well-paying job at Oracle.
Series A
The company has raised 3m from a big-name VC and the team has grown to 1015 people. Youve got your own office with your logo on the door, or at least
your own area in the coworking space.
The investor makes you submit quarterly cashflow reports, so you start keeping
accounts for the first time. This is done by whoever has Excel installed on their
computer.
The company eventually hires an office manager to ease the burden of
administration on the founders. They set up a payroll provider and start doing
peer reviews.

You join the company to do a specific role, but you spend your first week or two
figuring out what you should actually be working on. At least they remembered
to buy you a laptop, a desk and a chair.
There are 3 or 4 engineers in the team, so you start to do code-review and set up
a continuous integration server. You lament all the technical debt that was
accrued by those idiots who arrived before you, slowing down the pace of feature
development.
A new product direction for the company is decided in a meeting of the three
founders; this is presented in an all-hands meeting of 12 employees. The
company sets out a quarterly product roadmap, and youre asked what you think
should be prioritised. You pick the projects that most interest you.
Youll certainly be able to earn more money at a big company, but the salaries
are enough to live comfortably on. You get 0.5% in stock options with a salary
thats 10-30% below market rate. But you reckon its worth the gamble - if the
company sells, youll be able to buy a really nice house in London. Still, it feels a
long way off.
The marketing function is one full-time person who does everything from PR,
paid advertising and social media. The founder no longer personally runs the
companys Twitter account. Your company regularly appears in the ones to
watch articles in tech press.
Youve got thousands of paying customers, and you occasionally see people in
public using your app, which feels fantastic. Your mum isnt really sure what
your company does, but shes happy enough because youre being paid a real
salary.
Series B
The company is now 2-3 years old and has just raised 10-20m. Its using that
money to grow the team, increasing headcount to 60 people.
The founders got tired of the dingy office, so they splashed out on somewhere
with lots of exposed brickwork and glass walls. Everyone is sitting on Herman
Miller chairs. You find these chairs online and see they cost 1000 each.
There are 3 or 4 people in finance and HR roles, and youre presented with a
company handbook when you join. You have a couple of days training, but you
mostly figure it out along the way.

Marketing now has three digital advertising people, and people specialising in
PR, content and community management. Youve got millions of paying
customers in several countries, and your company is regularly featured in the
business pages of the press.
Engineering has been split into two or three separate teams, and theyre trying
recruit graduating college students to fill the hiring pipeline for next year.
You join in a very well-defined role, after the team manager recruited you. You
meet founders during your interview, but they dont always remember your name
now you work here. The CEO sees a management coach every fortnight.
A new product direction is debated at a board meeting, and senior management is
informed by the CEO. Management let their teams know that changes are
imminent. Most people are focussed on repeatable processes and scaling up.
The company doesnt seem to release new features very often, but the app is used
by some of of your mums friends, which makes her very proud.
Your salary is in line with what other companies are paying, and you get 0.05%
stock options. Youve already figured out which house youd put a deposit on
when the company sells. A sale seems inevitable at some stage.
Series C
Youre joining a unicorn! After 5 years, the company has raised 100m at a 1bn
valuation. There are some strange terms in the deal structure that youve never
seen before, but the companys HR department tells you thats just legal stuff.
When you join, youre granted 50,000 of options, which you work out is one
two-hundredth of a percent, or 0.005% of the company. Friends in other startups
tell you to check what the investors liquidation preference is, but no-one at the
company can seem tell you. Theyre all too busy trying to guess when the IPO is
going to be announced. You figure that any kind of payout is a nice bonus. The
salary is pretty decent anyway.
You join in the companys newly opened Dublin office, part of a new drive by
the company to internationalise. Youve joined as one of 6 new Sales Associates
focussing on European enterprise sales. Theres 4 week intensive induction
training programme before youre allowed to talk to any customers.
The new office feels empty at first, but youre surprised how quickly it fills up
with new staff. You ask where the marketing department sit, but youre told
theyre in a different office.

You see the CEO on the cover of Forbes, but youve never actually met him.
Your mum is already using the app, although its starting to look a bit dated
compared to some of the newer startups that are in TechCrunch.
Business Insider reports that the company has fired the new VP of Product and is
pursuing a new production direction. She had only arrived from Twitter 6 months
earlier. An internal memo from HR a couple of days says that the companys
doing some minor internal restructuring.
You see consultants in the meeting rooms, but you dont know what theyre
doing.
A month later, you gather for a televised all-hands meeting, broadcast from the
companys HQ. The CEO delivers a short speech announcing that the companys
been acquired by Oracle, explaining how it will accelerate the companys ability
to deliver on its vision. He thanks everyone for being part of the companys
incredible journey. People in the audience are crying.
HR follows up explaining that as part of the acquisition, some departments will
be downsized. Youre told that your stock options are underwater. When you
Google this, you find out that theyre worthless. Youve got some friends in
engineering who are being given Oracle stock as a retention package, but that
doesnt apply to anyone in sales. You wonder why you ever joined a startup in
the first place.