Teach-in on Lawyers Struggles and Recent History of Struggles in Pakistan
Scaling your startup from po c to production a tale of technological and human struggles
-
Upload
johann-romefort -
Category
Technology
-
view
170 -
download
0
Transcript of Scaling your startup from po c to production a tale of technological and human struggles
Scaling your Startup from PoC to ProductionA tale of technological and human struggles
Johann Romefort, Tech Evangelist @Stylight
Hi, I’m Johann!
● Tech Evangelist @Stylight
● Since 3 years in Munich
● A certain passion for building communities
● Before: 7 years in San Franciscobuilding startups
Program ● The Technical Cheat Sheet of Doing a Startup● The Human Cheat Sheet of Doing a Startup● Scaling your team & Building your network
The Technical Cheat Sheet of Doing a Startup
The Craziness of Building a Tech Startup
● Compressing time● Getting on the roller-coaster● Living in a bubble
PoC? Prototype? MVP? Production?
PoC: Demonstrate/Validate an idea - no UI required
Prototype:Get a step further and build something that people can play with
MVP:Get one step further and get it in the hands of future audience
Production: Shit gets real and so is a myriad of problems :)
Some deadly technical mistakes and oversights
1/ Premature Scaling
Premature Scaling 1. 74% of high growth internet startups fail due to premature scaling.
2. No startup that scaled prematurely passed the 100,000 user mark.
3. Startups that scale properly grow about 20 times faster than startups that scale prematurely.
4. 93% of startups that scale prematurely never break the $100k revenue per month threshold
70% of the startups are scaling prematurely
Source: Startup Genome Report - Data based on an analysis of about 3200 high growth internet startups
What’s premature scaling?
2/ Over-engineering
On the cutting edge of technology
Our product runs on Kubernetes, with fully containerized Rust microservices talking through a Kafka messaging queue, with a VueJS frontend.
We have 10 users, and growing fast.
Exotic tech stacks,just because you can
I built majestic monoliths for a living
Sounds cool!
What’s a Monolith and how do I build one?
● A whole system in one giant black box
● Much easier to build than distributed application
● You generally build one without even thinking about it
When does it make sense to build a monolith?● Proof of Concept ● Prototype● Early production
WHY?
● Because anything else before Product-Market fit is *NON-SENSE*
On being CTO at hot startup in San Francisco
My first year as a CTO● Put a monolithic prototype in production● With no monitoring● No continuous integration● No continuous deployment● No testing● … and kept adding features...
Codebase after a year
● Failing from everywhere
● Fixing one part created more bugs
● Developers scared to touch it
Deployements became HELL
● Bringing down the site for hours
● Lighting up candles
● Praying
● Rolling back
● Felt like russian roulette
Me, 10 years ago...
Oops, I crashed TechCrunch :)
How do we fix this? We patch it!
Hire a QA Manager● Create Testing/Staging
env.● Test > Stage > Deploy● Feared by the Devs● Hated by the CEO
Add an “Ops” guy● Create the build● Prepare the deploy● Locks everything so
devs can’t play with prod
● Wake up when servers on fire
● Also feared by the devs...
Impact of poor code base on developers
● Frustrated of slow release process
● Chain of Command way too long● Feeling powerless and scared● Low trust & Autonomy● High hit-by-the-bus factor
Impact on Product ● Frustration of slow
execution● Frustration of having to
ask for everything● No autonomy● Don’t understand
developers
Introducing:
BIG-BANG REFACTORING
Let’s rewrite everything from scratch!● Developers love it (they get rid of their tech debt)● Your CEO will HATE YOU.● Your Customers will HATE YOU.● You might never catch-up with your legacy system● You might just crash the company into the ground
What you should do instead
Break down application into smaller autonomous units, piece by piece.
Break down team into smaller autonomous units
Automate what can be automated Continuous Integration and Deployment, and devops your way to success.
Let’s get back to Microservices
● You’re in production ● Start to extract on well domain-defined part of your
monolith (ideally you did a preliminary work on that by designing your code in a modular way)
● Run it alongside your monolith, and have them communicate.
● Rinse & Repeat
An example of domain-defined microservices
Storage in Microservices
Servers in Microservices Architecture
30-seconds meditation on Conway’s Law
Introducing Cross-Functional Teams
● Autonomous team● Different set of skills
but working together● Own metrics and KPIs● Own software/DB● But new challenges...
Microservices + Cross Functional teams = Lean Enterprise
● Unless you don’t have Product-Market Fit - then it’s premature scaling :)● It’s not Unicorns and Rainbows either● The bigger the monolith & the more rigid the organization, the harder it is●
</microservices>
Looking for money? Let’s talk about Tech Due Diligences ● It’s a risk assessment of your technology● You need to prepare for it● Most likely you’ll be locked one full-day
giving details about your technical choices, your engineering team, etc..
Things to watch out for:
● Are you using any GPL code?● Do you have licences of all the products
you’re using● Ability to give a clear picture of the
architecture● Being transparent on technical debt and
your PLAN to reduce it.● Know where are the Single Points of
Failure in your architecture and have a PLAN.
● Is there any engineer that detain unique knowledge about a part of the code?
● What happen if X is hit by a bus?
Designing your architecture for scale
○ Simple tools for simple tasks○ Automate, automate, automate: CI / CD○ Make sure your code is 90%+ Tested○ Monitoring everything early on.○ Measure everything: Analytics are vital.
The Human Cheat Sheet of Doing a Startup
Managing Expectations (your own and other’s)
○ Energy Management vs Time management
○ How to say NO to your CEO○ Technical debt○ Virtues of being honest
with oneself and transparent with others
Things you always forget
The value of mentoring
Keeping focus
Sleep Paying it forward
This is where you ask me questions!
Scaling your team and building your network
Why is Hiring Tech People so Hard?
Source: StackOverflow Insights Survey 2017
Source: StackOverflow Insights Survey 2017
Source: StackOverflow Insights Survey 2017
Hiring the right people○ Let’s talk about Divas○ Slow Experts vs Scrappy Doers○ The “Hit-By-The-Bus” factor
Distributed Team or Onsite Team?● I’ve managed a team of 60+ engineers all over
the world:
○ Multiple US-location/timezones○ Bucharest○ Singapore○ France○ Germany
Where to find talents?
1/ Your employee network
2/ The network you’re building
3/ Recruiters? Eerr no thanks.
PAY IT FORWARD
It will eventually come back to you.
How can I help?
@romefort
http://linkedin.com/in/romefort