From 0 to $$$: Apiary’s Startup Lessons Learned Lukáš Linhart [email protected]
 @almadcz
 http://www.almad.net

280.000 APIs 2M+ Consumers 200.000 Developers Apiary CTO @ 5 year journey through unintended consequences

In this talk, I’d like to surface what’s under water: consequences of decisions, and trade-offs I haven’t been aware of. Who are you? Business people, Leaders / Managers, Developers? (Has bene ~60% of devs in the WebExpo audience)

One last thing: “It depends” (Context is crucial) There is no silver bullet. I’ll try to provide enough context to decide whether the context of my decisions was relevant for you. Act I: Is This Even A Thing Let’s start at the beginning of Apiary.

<“up and right graph” slide> Beginning of the exponential trajectory…but you don’t even have time to draw it, so you explain it and move on. Founder story to tell…

Jakub & Jan, our founders. Apiary was conceived on first node.js hackaton, later transformed into a company. Initial iteration done in Cambridge, UK in a startup accelerator.

Product SaaS company Apiary From the beginning, Apiary was designed as a Product (not service, not consulting, …) SaaS (no packaged software) company. Startup Apiary …and as a startup, word that is thrown around so often it became as meaningless as ‘agile’.

Startup “Startup is a temporary organization designed to search for a repeatable and scalable business model.” — Steve Blank I like Steve’s definition. Startup “Startup is a temporary organization designed to search for a repeatable and scalable business model.” — Steve Blank Startup is temporary: their goal is to cease to be a startup. Successful startup is called an Enterprise.

Startup “Startup is a temporary organization designed to search for a repeatable and scalable business model.” — Steve Blank Startup “Startup is a temporary organization designed to search for a repeatable and scalable business model.” — Steve Blank

Startup “Startup is a temporary organization designed to search for a repeatable and scalable business model.” — Steve Blank Startup “Startup is a temporary organization designed to search for a repeatable and scalable business model.” — Steve Blank

Startup “Startup is a temporary organization designed to search for a repeatable and scalable business model.” — Steve Blank Startup “Startup is a temporary organization designed to search for a repeatable and scalable business model.” — Steve Blank

What’s not there… Financing Industry Free Beer Venture Capitalist backed Silicon Valley startup We want a bit further, to be archetypal startup: with VC funding and based in SV.

VC economy (9/10 companies fail, 1 kinda pays for itself, even less are providing those 10x+ returns) requires unicorns (valuation $1B+) to function. Hence, you need to aim to be an unicorn or die trying. Liquidity event mandatory In order for cash-flow to work, there needs to be one of those outcomes: 1) IPO (liquidity via public markets), 2) M&A (liquidity provided by larger company) 3) You die (and stop taking more money in). All are fine. Having $1M in revenues is a failure—not enough liquidity for investors, with ROI way too long.

Why to VC? (Network effect—winner takes all) In dev tools, winner takes most of the market. We see it as well—without VC money, we’d already be just a footnote. Silicon Valley Yes, we wanted to go there from the beginning.

It’s a special place. Not because of money or coolness index, but because of network and access to accumulated knowledge. Stage 1 Goals Get some interest (maybe few beta users) Plan what are you going to make money on Get it running But back to the Cambridge basement.

Act II: Early Traction Once you are done, you move on to find your early traction. You are roughly here. Y Axis represent users, employees and traffic. Also, only post-series-B companies label Y axis.

Initial money provided by Angel investors. We are grateful to Esther for trusting us. Stage 2 Goals Start getting active users (more important) Figure out money engine (less important)

1st Employee (Hence my story to tell) From those money, you hire first people to help you. This is where I came in, so I can provide my own perspectives. It feels like this.

Protoduction is my favourite startup word: prototype running in production. A feature a day (A milestone every week or two) You need to move very, very fast as you’ll have a big feature churn.

Building a mess (Try having it well contained) F O C U S

Pay-as-you-go SaaS = Gift from God Design for quick change (Smaller is better)

Use weekends wisely (Velocity gained vs. problems created) First brave colleagues

They are the culture Culture (n) “What people say about your company when you are not in the room” “Companies don’t have culture, companies are culture”

They are future leaders (Even if they will be not) Even if they will not be appointed managers formally, they’ll be approached for help, and they will set what will be status quo in the future. Cohesion = Blind Spots (Hiring for tribe vs. hiring for diversity) Diversity has been hijacked to mean gender or race, but it’s much broader then that. It’s about difference in thinking, social and cultural background. It slows you down as you need to learn about communication patterns, but a lot of innovation comes from that.

Hiring time, writing time (~80 rounds for ~5 people) “Hire fast, fire fast” — What everybody says (and nobody does, even in US)

VPE & CTO (You are manager now, focus on team) Visibly lead by example (Will kinda work for a while) The “visible” part is important: what is not communicated will not be replicated.

Act III: Scaling Attention Now you need to get take over the bottom market and get some money out of those people. May look similar to previous one…but actually it’s 10x scale. Our ambitions are scaling as there needs to be a unicorn in the upper right corner.

Jakub moving to US

Our heavybit offices. Our HB neighbours. They are awesome.

CxOs are aligned (or you will die) Trust is essential (lose of cross-ocean control)

Remote is hard (Avoid it if you can, scaling empathy is hard already) Building Engineering (on both sides of the ocean)

Last call for responsibilities (CD, Operations, User Support, …) So You Want US Engineers?

Same culture, small differences™ Culture is similar enough to bring in assumptions, which is the most difficult part. I will list some of the things I’ve discovered affect work life maybe most. Vacations There are 2 weeks of vacation in US by default (incidentally, same as notice period). People mitigate by taking sabbaticals (few months off) between jobs, and they are changing jobs more often on avarage.

Medical & Parental leaves Parental leave is like 6 weeks. People tend to take absolute minimum of medical leaves. At-will employment Everybody can be fired instantly. Everyone can leave instantly, it’s a good habit to give 2 weeks notice. Compensation package is not mandatory, and usually much much less than in EU (talking about the minimum required by law).

The Power Pyramid (1-1s help) All of those causes people to observe the titles and power structure much more, to be much more obedient (comparably) and to have troubles to speak up. 1-1s (30 min unstructured time every week) help, and you really need to focus on psychological safety there, and it really takes quite a few of them to achieve that. “Political correctness” (actually respect…and it works) A lot has been said about this part of US culture, let me just summarise that a good guideline is to image a word “respect” instead. It’s much more colourful there and it’s a good way how to learn how to live together. Just be careful to learn at the beginning, as you are just oblivious.

Complaints not welcome (and yes, it affects group dynamic) Complaints and cynicism create a feedback loop that’s hard to break, and neither is very popular in US. It doesn’t mean you can’t point out things are broken, but it’s a different framing and different way of formulating those, and I think it’s actually something to learn from. Junior is Junior, Senior is Senior There is much higher disparity between junior (someone coming out of code school) and true seniors (someone building internet infrastructure and having RFCs under their belts) than here.

Beware of satellite workers If you are building US engineering, I strongly recommend having an office, and having sufficient size. Remote-first can work as well—just not having few persons attached to a remote team. You are manager now (Leadership and influence) As for me, I became full-blown manager. Hardest part is that your personal productivity doesn’t matter anymore, the earlier you accept that, the better. Your productivity is your teams’ productivity. Your tool is not code anymore, but leadership, influence and communication. Beware of being perceived as manipulative.

Delegating early vs Not trusting When you are not delegating, it seems you are not trusting people. When you delegate too early, the problem is that you are still responsible for result. I really recommend adding monitors and checks into what you’ve delegated, at least in the early days. You definitely needs to have a clear plan and communication when it fails. Transparency = Uncertainty Being transparent unfortunately mean exposing uncertainty that goes into decision-making. As you grow, you’ll hire people that can’t take it, and you are going to cause a lot of emotional churn. I’ve raised the bar of certainty required for sharing.

Uncertainty doesn’t scale It Will Be Your Fault Anyway (Learn to live with it) You productivity is team’s productivity, all their aggregate faults are your responsibility. Learn to live with it, and learn to put your ego away, otherwise you’ll not survive in the long run. It’s also a point where you may need to start to meditate, sport or drink to cope.

Act IV: Learning To Sell OK, we’ve taken over the market. Now, let’s optimise on how to really sell this to all those users and turn them customers.

Series A $6.8M You get a reasonable money for that. Only goal: build a black box. $1 in, $3 out.

“Use the money to fix what brought you to Series A” This is also the time to fix your (not only technical) debts. Protoduct no more No more protoduction, time to build the real production application.

Scaling non-engineers Adding a lot of non-engineers is going to affect the culture. Structure, do you need it? (look up Tyranny of Structurelessness) Implicit structure without explicit structure provides unclear responsibility and accountability.

Communication trade-offs Being direct vs Being slow

Quick autocracy vs Long group discussions Group discussions means meetings and everybody hates those. It’s hard to get true ownership and acceptance without them, though. Open mind vs “No vision” perception When you are open to changes, you can be perceived as being without vision. Choose wisely what to communicate.

Building Teams Vertical > Horizontal Avoid handovers (like plague) Sense of ownership crucial Team Problems Diverging culture Fragmented stack Team first (not Company first) Team first (not Team Leader first)

Remedies 1-1s flow Focus on cross-team “lean for help” Single responsible person (for cross-team things) Well-defined Team interfaces Team Leaders doing hard soft work Pivoting to Enterprise! We also discovered TAM in SME is too small for us and that we want to sell to enterprises. It was a bit like rebuilding the company mid-fight.

Cultural shift (Don’t underestimate those when ownership is high) Bringing in Product Manager (Removes Engineering empowerment & adds process) As we’ve lost close empathy with customers, we needed to bring PM in, also with trade-offs.

Bringing in Sales (Yeah, those guys. They help) Sales may have bad reputation among engineering, but they truly do help. And they are basically required for high-touch customers. Expectation changes (CISO strikes back) Expectation on your product changes: CISO is going to call you and send you security reviews. It’s a lot of work.

Act V: Scaling the Magic $ Box Well, you’ve learned to sell. Now it only means scaling it to address the whole TAM and to expand the whole marekt. Yeah, expectation change again.

Laser focus (and metrics) He was right

Know your verticals ROI language of decision makers We had to change a lot of the language from developer-friendly to business-friendly. It hurts and it helps.

But in the end, this will be another talk if we’ll be a unicorn. So far, we are only baby unicorn—so, see you in a few years. Start the journey Instead, I’ll encourage you to start your own journey. Step up, tech leaders are needed. Found a startup, or join one (if you don’t know which one, we are hiring).

@almadcz Thank You @apiaryio http://apiary.io/ Credits Unicorns: Photo Credit: SERRESUNDIAL via Compfight cc Iceberg Photo Credit: Photo Credit: alejandrogallegos90 via Compfight cc Question mark Slide: Photo Credit: Leo Reynolds a> via Compfight cc Esther Dyson: By James Duncan Davidson from Portland, USA (Etech05: Esther) [CC BY 2.0 (http://creativecommons.org/ licenses/by/2.0)], via Wikimedia Commons Cambridge: By Christian Richardt [GFDL (http://www.gnu.org/copyleft/fdl.html), CC-BY-SA-3.0 (http://creativecommons.org/ licenses/by-sa/3.0/) or CC BY-SA 2.0 (http://creativecommons.org/licenses/by-sa/2.0)], via Wikimedia Commons