Having worked in the mandatory growth or death part of the tech industry1 for a few years now, I've had some chances to see how organizations evolve as they grow. Not just evolve as an organization, but the technical environment. I've talked about this before, but what's most important for a mandatory-growth company changes based on their market-stage.
Early stage startup (before product-release to the months after the product is released)
- Finding market-fit is everything.
- The biggest threat to the infrastructure is running out of money.
- Get out the tech-debt charge-card because we need to get something out there right now or we'll need new jobs.
- Feature delivery way more important than disaster resilience.
Middle stage startup (has market-fit, a cadre of loyal customers in the small/medium business space)
- Extending market penetration is the goal.
- Feature drive is slacking a bit, focusing on attracting those bigger customers.
- Some tech-debt is paid off, but still accumulating in areas.
- Work on improving uptime/reliability starts coming into focus.
Up-market stage (attempting to break into the large business market)
- Features that large businesses need are the goal.
- Compliance pressures show up big time due to all the vendor-security-assessments slowing down the sales process.
- First big chance of a major push to reduce early-stage tech-debt. Get those SPOFs out, institute real change-management, vulnerability assessment program, actual disaster-recovery plan, all the goodies.
These are very broad strokes, but there is a concept called technical maturity that is being shown here. Low-maturity organizations throw code at the wall, and if it sticks in an attractive way, leaves it in place. High maturity organizations have perfected the science of assessing new code for attractiveness and built code-deployers that can repeatedly hit the wall and maintain aesthetic beauty, all without having to train up professional code-throwers2.
Maturity applies to Ops processes just as much, though. Having been working on some of this internally, it's come to feel kind of like building a tech-tree for a game like Starcraft.
Logging/Metrics/Observability
Level 1: Centralized logging! And you can search them!
Level 2: You've got metrics now!
Level 3: High-context events!
Level 4: Distributed-tracing!
Disaster Management
Level 1: You've got an on-call system and monitoring!
Level 2: You've got a Disaster Recovery plan!
Level 3: You've got SLAs, and not-Ops is now on-call too!
Level 4: Multi-datacenter failover!
Patching
Level 1: You have a routine patching process!
Level 2: Patching activities not related to databases no longer require downtime!
Level 3: You can patch, update, and upgrade your databases without requiring downtime!
Level 4: You can remove the planned outage carve-out in the SLA's uptime promise!
These can definitely be argued, but it looks like it might be a useful tool for companies that have graduated beyond the features or death stage. It can let internal technical maturity take an equal place at the table as Product. Whether or not that will actually work depends entirely on the organization and where the push is coming from.
1: As opposed to the tech enables our business, it isn't THE business part of the industry. Which is quite a bit larger, actually.
2: This analogy may be a bit over-extended.