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!