Before I had a name for “terrain”, I was living it.
When I set out to build the SaaS platform that would become the core revenue engine of the 200+ person law firm I came to lead, the database and data model came first.
The shape of the entities. How they would operate in a multi-tenant SaaS environment. How they would connect into the workflows our business (and our clients) actually needed.
That was the foundation everything else got built on.
Don’t Agile Your Database Design
Database design is systems-level work, and that kind of work does not decompose neatly into two-week increments. You do not ship half a schema and iterate your way to the other half.
Get the data model wrong, and you do not just create a detail grid with unwanted horizontal scroll. You create bad data that propagates into reports, calculations, workflows, and decisions someone downstream is trusting to be correct.
And in a regulated environment, the database also carries the real regulatory risk – not the navigation or a button color.
So I built it the way it needed to be built: deliberately, completely, before anything else touched it. Call that waterfall if you want. I call it doing the dangerous part first, and doing it right.
Once that foundation was solid, everything changed.
The same discipline that made sense for the database became a liability for the application layer sitting on top of it.
Batching feature releases into six-month cycles was not rigor anymore. It was drag. Clients wanted fixes faster. Bugs that touched core data could not wait for the next scheduled release.
So I changed gears, moving to weekly releases, and a few years later wrote about what that shift taught me when I formalized it with a CSM.
Same product. Same regulated environment. Two operating models, applied in the order the work demanded.
This is the part most speed-versus-governance arguments miss. They treat it as a question of which camp you are in – agile or waterfall, fast or careful – as if a system picks one and stays there.
Mine did not. The database needed one gear, and the application layer needed another. Both were right, for what they were, when they were.
Map Your Terrain
Today, I look at delivery through a simple lens: balance the business risk against the actual need for speed. When you plot those two things against each other, you usually find yourself dealing with four very different zones.
On one end, you have low-risk, high-speed work – things like marketing landing pages, campaign funnels, or lightweight internal workflows. If a button breaks here, it’s annoying, but it’s entirely reversible. The cost of sitting on your hands out of a desire for “perfect governance” is almost always higher than the cost of a quick mistake. This is where you push Agile, automation, and CI/CD as hard as you can.
But that exact same playbook becomes a massive liability the second you step into high-risk, low-speed terrain. If you are touching financial ledgers, security protocols, or compliance audit trails, nobody cares how fast you ran if the data is wrong. Velocity is great and all, but correctness is the table stakes. You need formal reviews and architectural discipline, and you shouldn’t apologize for them.
The hardest bucket is the high-risk, high-speed zone – things like core revenue platforms or customer-facing transaction engines that require both massive throughput and absolute precision. The trap here is falling back on slow, bureaucratic approvals – or having your board or executive team think everything should sit in this zone. The actual answer is mature engineering: automated testing, deep observability, and fast rollback capabilities so you can move safely without grinding the business to a halt.
And some low-risk, low-speed systems may not deserve much investment at all. The right answer may be simplification, retirement, consolidation, or “good enough” maintenance.
In my experience, you can’t evaluate delivery speed in a vacuum. You have to know where that speed acts as a force multiplier vs. where it acts as a fire accelerant.
Terrain Does Not Stay Put
My SaaS platform was the first example. The database phase sat in high-risk, low-speed terrain. The regulatory exposure was real, and that work had to be deliberate. Once that foundation was solid, the application layer moved into a different high-risk, high-speed mode: still regulated, still important, but now able to move quickly on top of a stable base.
That is the transition many organizations struggle to make. They either keep the brakes on too long, or they hit the gas before the foundation can support it.
Terrain can also shift through integration, especially when the request is cross-functional.
An example I’ve seen, and common in mid-market orgs: Marketing asks for ERP data to improve segmentation or campaign targeting.
Marketing thinks they’re just asking for a quick, low-risk data dump for a campaign. They aren’t. The second that request hits the customer master data or pricing logic, they’ve crossed the border into high-risk territory – whether they realize it or not.
The ask, then, is no longer just helping a fast-moving team execute a campaign. It becomes exposing enterprise data safely, consistently, and with enough governance that downstream users do not make decisions based on misunderstood or unreliable information.
I’ve also seen a harder version of this problem: The requesting team goes further than just wanting to consume upstream data, asking the system of record to also change its definitions or operating model to match the downstream tool. We’ve now got an enterprise governance decision masquerading as an integration request.
When this kind of friction shows up, governance has to apply – but “because, governance” is not the right answer. That usually just devolves into a power struggle over who controls the rules.
I’ve found the better answer is a translation layer or domain-specific semantic model that lets the business move quickly without corrupting the source of truth. Done well, this approach keeps the work closer to the lower-risk terrain where it started, instead of dragging the entire enterprise system of record into a local workflow dispute.
And, I want to be real here: This all sounds simple when I write it out, but I’ve spent more nights than I care to admit ruminating about how to crisply explain to an executive panel why casually changing the system of record can negatively impact financial outcomes.
Technology Leadership = Commercial Leadership
Too many technology leaders choose between speed and control based on dogma. I believe the choice should instead be driven by the terrain, creating an operating model that knows when it is appropriate to hit the gas, and when it is reckless to do so.
Agile, DevOps, CI/CD, automation, and modern tooling can help companies move faster. I believe in that. I have lived that.
But speed is not automatically maturity, and governance is not automatically wisdom.
The job is understanding the business terrain well enough to know where speed creates value, where control protects value, and where the wrong operating model creates risk faster than the company can recognize it.
Because technology either helps a company make money, protect money, serve customers better, move faster, or reduce meaningful risk. Otherwise, it is just an expensive decoration.
–Scott
