(Note: For simplicity, I'll refer to web operations, server systems, devops, and so on as simply "Ops" or "systems".)
Do what others consider impossible
Do you ever wonder how some companies can scale to over $100,000,000 in annual revenue with less than 20 hours per week spent on their Ops?
I've had at least one client that has been able to do exactly that. I've also had dozens of smaller clients who have been able to scale to multi-millions of dollars of annual revenue with under 10 hours per week spent on Ops.
Unfortunately most of the 300+ startup systems I've reviewed greatly over-engineer parts of their systems while leaving other parts critically under-engineered. The result is overly complex systems that require a ton of maintenance, yet are still open to huge risks.
The "default" ways are SLOOOOW
It's not necessarily the engineer's fault that they don't know how to get the right balance. The default way to create systems is to follow the well-respected examples of others. Seems perfectly reasonable, right? Well, it seems reasonable, but it is SLOOOOOW and hugely inefficient. Here's where this "default" strategy fails:
- The example you're copying is from a system with different needs than yours. I can't tell you how many small-and medium-sized companies I've come across that use Netflix or Google as a model for their systems. They end up wasting a ton of resources trying to do things that only make sense at truly massive scale. Ultimately, they end up throwing away their competitive advantage and making it way less likely to ever coming close to the massive scale they're trying to emulate.
- The example you're copying is a copy of a copy of a copy. And that copy is 20 years old. News flash: the Ops world has changed a lot since then! In my consulting I often come across modern companies making decisions that would've only made sense in the 1990s. Insanity!
- The example you're copying is marketed as "modern" or a "best practice" despite being neither. There are certain phrases that engineers are suckers for: "modern" (don't want to be old-fashioned!), "best practice" (don't want to be worst-practice!), and even "open source" (that makes it totally free with no vendor lock-in right?! No? Uh-oh).
Unfortunately, this "default" way of building and running systems will be with us for the foreseeable future. Here's why:
- It feels right (even when it's not). When a high-status company has done something, then it feels like you get a little of that status by doing the same thing. It's easy to justify doing that thing because Some-High-Status-Company also did it.
- It makes the right ways feel wrong. There's so much momentum for the defaults that often when I show engineers how to do something far simpler and cheaper, it will just feel "wrong" to them. They don't realize that much of what they feel comes from the marketing of software vendors, infrastructure companies, and Ops consultants that push their own preferred ways of doing things. Those guys may be acting in good faith, but they have a huge disincentive in you having simpler systems. In nearly every case it means less revenue for them.
The effectiveness of your systems is NOT measured in feelings!
The effectiveness of your systems is measured in how efficiently they serve your company's goals. Goals like:
- Extremely low maintenance
- Low cost
- High reliability
- Robust security
- Readiness to scale
- Ease of hiring
- Support for high-speed development
That's what this training program is about: learning how to get beyond the alluring, yet painfully slow defaults and instead use High Velocity Ops.
With High Velocity Ops, instead of copying from the examples of others, we start from the foundational First Principles, and from there, learn the strategies for building extremely simple, robust, low-cost systems.
Reasoning from First Principles
The systems engineering field is still in its infancy. Many "expert" systems engineers are encyclopedias of low-level technical knowledge, but don't have a grasp on the key fundamentals.
And it's those fundamentals that make the difference between speed and excruciating sluggishness for business growth.
The best way I've found to teach modern systems for maximizing business growth is to start from the basic foundations and work up from there.
Elon Musk explains the First Principles approach:
"First principles is kind of a physics way of looking at the world. You boil things down to the most fundamental truths and say, 'What are we sure is true?' ...and then reason up from there."
To describe the power in this, he gives a great example:
Historically, battery packs cost $600 per kilowatt hour. People assume that's just the way it is. But, if you look at the basic elements of a battery pack, you see that it is just a combination of elements like cobalt, nickel, aluminum, carbon, and polymers put in a sealed can. However, if you look at the costs of those individual materials and add them up, it comes to only $80. So, then it's just a matter of coming up with a clever way to combine those materials — then you can create a dramatically cheaper battery pack.
The advantage of First Principles is that it cuts through all the outdated traditions, zealotry, and hyped-up fads around systems.
Without building from First Principles, there is often a lot of, "But some Unicorn company did it this other way!" or, "But so-and-so expert said this one thing!"
Using First Principles establishes clearly what you need and what you don't.
Many systems are not built from First Principles, and this is how you can tell:
- There's a bunch of complex expensive-to-maintain crap they don't need
- There's a bunch of absolutely critical things missing
Without building from First Principles, your systems end up:
- Exposed to catastrophic risk
- Requiring 5 to 50 times more engineering hours than necessary
Even engineers who are considered technical geniuses fall into these traps. They get caught up chasing every new fad and adding it to their systems. Despite their technical prowess, if you look only at the business metrics of their systems, these technical-marvels-of-waste are indistinguishable from incompetence.
How This Benefits You
Any sufficiently technical engineer can set up systems that wastefully drag along at 5 to 50 times slower than needed. That is neither rare nor valuable. Lots of people do that. It's sadly quite common in our industry.
This program prepares you to be one of the most powerful engineers when it comes to maximizing your systems for the fastest business growth. This is very rare and very valuable. It will benefit you throughout your career whether you're an early engineer at a new startup, a CTO running an engineering team at a larger company, or a founder of your own venture.
If you’re a current or future engineering leader:
- Clearly understand what good systems look like and know how to show appreciation for quiet, cheap, stable systems
- Retain the talented engineers that make these ultra-efficient systems possible before they’re snatched up by competitors
- Know exactly what to look for when hiring top systems engineers, which means seeing beyond resumé buzzwords and selecting those who can deliver on the metrics that matter
- Sleep better at night knowing your company’s Ops are running smoothly without your direct supervision
- Free up a surplus of engineering hours that you can use for more valuable projects
- See through bad systems advice and protect your team from falling victim to it
- Use First Principles to help your team understand the big why behind the High Velocity approach
If you're an engineer responsible for Ops:
- Free up your time for more interesting and valuable projects
- Learn how to demonstrate your high value to your company —which can be a challenge since the best systems are the most quiet
- Avoid the traps that lesser engineers fall into when trying to show their worth via heroics and unstable on-fire systems
Program Specifics
We'll cover 10 modules:
1. Strategies for Maximizing Growth
- Closer look at the purpose and benefits of these strategies
2. Navigating Hazards
- Countering bad advice
- Most common mistakes
3. First Principles: Business Growth
- Ops role in business growth
- How bad ops slows business growth
4. First Principles: Systems
- The fundamental purpose of the system
- The components of the system
- The fundamental needs of those components
5. First Principles: Workflows
- Fundamentals of system workflows
- creating environments
- regular recurring tasks
- as-needed triggered tasks
- recovery workflows
6. Strategies for Speed: Don't Die
- Mortal risks
- Crippling risks
7. Strategies for Speed: Avoid Slow Downs
- Key factors that slow down growth
- Strategies for countering each slowing factor
8. Strategies for Speed: FULL Speed
- Key factors for maintaining top speed
- Developing engineers with systems speed skills
9. Strategies for Speed: Scaling
- Scaling principles for maximizing speed
- How to not throw away your advantages when at smaller scales
- How to keep costs low when scaling your team
10. Strategies for Speed: All hands on deck
- How to sell the benefits of High Velocity Ops to engineers
- Calling out bad system smells
- Reward what is impressive
- How to maintain visibility for invisible systems
A Great Investment
While it's impossible to estimate exactly, since it depends on your scale and business situation, this program can save you and your company thousands of engineering hours and millions of dollars.
The sooner you get started, the sooner you'll have the power to boost your systems for speed and create an advantage over your competition. Oh, and not to mention, free up your own time for more interesting projects.
Answers to Your Questions
Am I a good fit for this?
If your top priority is creating great systems that deliver on the most important business metrics for your company, then yes!
If you're a good fit, you care deeply about:
- Extremely low maintenance
- Low cost
- High reliability
- Robust security
- Readiness to scale
- Ease of hiring
- Support for high-speed development
The folks I've found that are typically a bad fit for this are those who:
- Only care about the technology and ignore how it impacts the success of their business.
- Can't break from tradition and must always follow the crowd, no matter how slow they're going.
- Are addicted to heroics and must keep their systems in a constant state of adventure/peril so they can be the perpetual hero.
What scale do you cover?
This program covers scale from the very early seed-stage startup to companies with annual revenue up to $1B. Of course, revenue is a very loose indicator, but it will be accurate in most cases. We don't cover scale that requires building your own data centers, etc.
What if the program isn’t for me? Can I get a refund?
Absolutely. You can sign up for the program and get a full refund if you cancel before the last session.
No questions asked, no hard feelings — just a fair refund if it's not for you.
How long is it and how is it delivered?
About 7 hours of instruction and 2 hours of group systems consulting delivered live via online video (~9 hours total). We break the instruction up into sessions over several days.
How do you know this stuff?
I've been lucky enough to learn from a lot of data points.
I've been doing systems speed-up projects for over a decade. I've worked formally for over 120 clients and have completed over 200 contracted projects along with several hundred informal systems reviews along the way. Many of the paid gigs were short-term automation planning projects when I offered an automation "Jump Start" package. A couple dozen engagements were longer-term training and support contracts.
A few of my past customers: American Cancer Society, Ansible, Bravo, Brooks Brothers, CBS, CNET, Egghead, Elle, Google, Intuit, LexisNexis, Maxim, Mensa, New York Times, PacSun, Scribd, Showtime, Sony, Time, Town & Country, University of Maryland, U.S. Department of Defense, USA Today, Victoria's Secret, VMWare, Whole Foods Market, and Yahoo!
Ultimately my engagements have been focused on setting up systems for maximum speed and reliability. I've been able to see over and over what works and what doesn't.
What I teach is very light on theory. Instead, it draws on what I've learned from these hundreds of production systems.
Data Points
Here's a rough approximation of system's overspending (in time and money) by companies I've seen:
As you can see, most of these data points contain those red and orange dots which represent companies that are greatly overspending on their systems (by 5-50X). That overspending is mostly in engineering time, so when they could be completing a system project in 1 man-month, they are completing the project in 5 to 50 man-months.
Those inefficiencies are very common —so much so, that many engineers believe they're the norm. They may have only seen a misleading sample of slower systems and so aren't aware of how much better systems can be.
Fortunately, there are great counter-examples: the green dots which represent companies that are closer to the "ideal" minimal cost and maximum speed. An example of one of these is a client I had that was making over $100M in annual revenue (similar to Github's 2016 revenue). Their systems were so simple and robust that it took less than 10 man-hours per week to manage their systems. They had no dedicated Ops staff, the systems were just run part-time by an engineer who spent most of his time doing development (though he was a fully-qualified sysadmin).
I've had probably a dozen clients with systems that efficient. Clients whose systems are so well-built, they take very little maintenance — so little in fact, that many other engineers find it hard to believe it's even possible.
Of course, different systems have different needs and different legacy histories, so not all companies can have systems as lean as in the previous example. But, chances are, there are amazing opportunities to improve your systems and you can be the one to make it happen.
Do I need a technical background for this program?
Not really. This is primarily a strategy training program. I've even taught this material to business executives and they fully understood it (though I did take a little extra time to explain some concepts like DNS, network encryption, etc).
Approximately 95% of the program requires no previous technical background. For the 5% of the program that requires a bit of technical explanation, I'll let you know ahead of time the concepts you'll need to understand. It's not a lot.
In my experience, it's the basic strategies where systems most often fail. With the wrong strategies, no amount of technical brilliance will save your systems. That's why this program focuses primarily on getting the strategies and First Principles right.
Can I ask questions?
Absolutely. There are regular Q&A opportunities throughout the program.
Can you help me with my particular systems?
Yes —in the group consulting sessions I'll be happy to answer these questions. Keep in mind though that this isn't a deep technical program, so the questions should be primarily focused on the system strategies.
If you'd like private consulting where we review your company's systems and create a customized speedup plan, see the Services section.
I'm embarrassed about my systems.
Will you judge me?
You don't need to worry about feeling embarrassed about your current systems when we work together. Your systems have gotten your business to where it is now. That's awesome just in itself. We won't worry about the past — our only aim is to evolve your systems to become even better at achieving your business goals.
I've made nearly every mistake covered in the program at some point in my career. I've seen many of my engineering idols at the top companies in the world make these mistakes. So don't worry, you're in good company ;-)
What about privacy?
I do not share system details associated with the company's identity without written permission or unless the details are already public. I will share generalized system stories anonymously but I always change any details that could possibly be used to identify the company. I do share the company names of my notable past corporate customers in a general list unless I've made a special agreement with them beforehand.
Will you sign my NDA or other contracts before working together?
Sometimes, but I have a significant surcharge fee for this since I need to take time to review it and have my lawyer review it, etc. Contact me with the details and I'll provide you a quote on the fee.
I'm still not sure if this is for me. How can I learn more without taking the program?
That's no problem. This isn't for everyone. I'll be writing regularly about many of the topics I cover in the training programs and you can receive that content for free if you are subscribed to the email newsletter: