Scaling CTO / On Freund
-
Upload
geektimecoil -
Category
Technology
-
view
32 -
download
0
Transcript of Scaling CTO / On Freund
The Scaling CTOOn Freund
VP Engineering, WeWork@onfreund
Who am I?
VP Engineering @ WeWork
Distant past:
● VP Engineering @ Handy● Director of Engineering @ Safend / Wave Systems● Software Engineer @ Applied Materials
Your new startup
Your mature tech enterprise position
That corporate gig
Your side project
You need different skills when you scale
But what is scale?
Team CodebaseTraffic
It’s all about the culture!
What changes for you?
● Support system● Speed● Ability to change course (turning radius)● Protection / Safety
Race car / Early stage funded startup● You’re still driving!● You’re as fast as you’ve ever been● Steering has an immediate effect● Safety is an afterthought, but track is usually clear
What’s worse - losing or crashing?
74% of failed startups in first 3 years are due to premature scaling
● You have a crew, but you’re leading by example● You’re even faster than a race car but it feels slower
○ Changing course is hard○ You’re seeing everything from 30,000 feet above
● Safety, safety, safety
Communication is key - with tower, crew, passengers
Commercial flight captain / Growth stage startup
1. Course correct2. Let pit team know3. Longer term fix at next
pit stop
Production bug
1. Alert stakeholders2. Slack war room3. Blameless and
transparent post mortem
Production bug
Why are we moving so slowly?
You’re moving faster, but course correcting is inefficient
● Look at all that crew…● Crew is not only large, it’s also specialized● Traveling at warp speed but the course has been set in advance● Addictive luxury
"Traveling through hyperspace ain't like dusting crops, boy! Without precise calculations we could fly right through a star or bounce too close to a supernova, and that'd end your trip real quick, wouldn't it?"
―Han Solo, to Luke Skywalker
Spaceship / Mature tech company
Conway’s law is now your best technique to impact product!
“organizations which design systems ... are constrained to produce designs
which are copies of the communication structures of these organizations”
- M. Conway
Corollary #1: Changing how people communicate changes your product
Corollary #2: System design patterns might apply to teams
Conway Example #1: The big fat monolith
Breaking the monolith is easy: break the monolithic team!
● UI, backend and application teams● Like the “real” MVC, simple changes might require
modifications in 3 places● Integrations are the weakest link● At Safend:
○ Integrations with MVC teams: 1 week○ Integrations with product teams: 30 minutes
Conway Example #2: The MVC org
● A team that everyone depends on● Like a component that everyone depends on, the team
can never be down● Decouple / introduce redundancy
Conway Example #3: The infrastructure team
● You have a crew, and it’s been awhile since you’ve held the helms● Slower than a regular car, and hard to maneuver, but hauling thousands of
containers ● Changing course begins with shouting a command● Your only concerns are weather (economic climate) and pirates (disruptors)
Cargo ship / Evil Corp
● Different stages require different skillsets● Understanding which vehicle you’re driving is key● Understand the difference between speed and agility● As you make transitions, focus more on communications and
less on code● Use conway’s law to your advantage
Summary
Questions?
Thank you!