North Star Direction: Gerald Vrana (Sportradar Media Services GmbH) on 10 Engineering Principles to Deliver Customer Value in a VUCA World

Why this session matters now

From the DevJobs.at editorial seat, “North Star Direction” by Gerald Vrana (Sportradar Media Services GmbH) lands with practical urgency. Vrana’s team builds a self‑management platform in the sports betting industry—a domain where traffic spikes, hard deadlines, and shifting requirements are the norm. His talk makes one point crystal clear: in a VUCA world, certainty is a myth. Teams need direction, not detailed maps. The North Star is that direction.

Rather than chasing silver bullets, Vrana offers ten grounded guidelines any engineering team can put to work today. The emphasis is on decisions: countless choices, every day, often under pressure. A clear North Star filters those choices and keeps value delivery on track.

VUCA: the environment we actually ship into

Vrana opens by framing reality: the world is “far from being a perfect place.” He invokes VUCA (a term dating back to the 1980s):

• Volatile: changes are rapid and unpredictable.
• Uncertain: the present is unclear, the future is uncertain.
• Complex: many interrelated factors can cause chaos and confusion.
• Ambiguous: there’s a lack of clarity and awareness.

In tech, that translates to flickering requirements, service outages, and sudden customer requests. Nothing is set in stone—so structure your engineering to embrace change rather than fight it.

The North Star: guidance, not a map

The North Star won’t show a step‑by‑step path; it will guide your direction. Vrana shares a relatable analogy: planning a trip from Vienna to Linz, the mode of transport was undecided—car, train, motorcycle—but the direction was obvious: roughly two hours west. In engineering terms, a North Star answers “which way” when you’re unsure whether to go left or right.

He also highlights the decision load we all face—so many choices, almost every couple of seconds. Without a guiding direction, teams drown in ambiguity and second‑guessing. With one, prioritization becomes natural: choose the option that best aligns with the direction.

The ten guidelines of “North Star Direction”

Vrana distills his approach into ten principles. They’re deceptively simple, but they demand discipline. Below we expand on each, strictly grounded in the talk.

1) Customer‑obsessed: work backward from the customer, prioritize NFRs

Deliver the right value at the right time. A feature that ships months after the need has passed has no value. Vrana also insists that non‑functional requirements sit at the top of the priority stack:

• Availability and scalability matter most.
• If a product becomes unusable under high load, it delivers zero value.

Practically, that means building for high concurrency, stability, and predictable latency. In a North‑Star frame, NFRs aren’t “hygiene”; they are core value delivery.

2) Cross‑functional and self‑sufficient teams

Vrana argues for teams that hold end‑to‑end capabilities: designer, architect, developer, QA. He recounts the frustration of waiting one to two weeks for a production database dump because access sat with a separate admin team. In a VUCA setting, that delay is intolerable.

Cross‑functional teams shorten feedback loops and reduce coordination drag. They keep knowledge local and ensure issues can be diagnosed and resolved without hand‑offs.

3) End‑to‑end ownership: you build it, you ship it, you support it

Ownership doesn’t end at merge. In Vrana’s words:

“Done” is only when it’s in production and usable. This principle anchors engineering in outcomes, not outputs, and pushes teams toward testable design, production‑ready code, and smooth operational practices.

4) “Keeping the Hostage”: resilience against attacks and total outages

One of the toughest—and most crucial—principles is handling a hostage scenario (e.g., a ransomware event). Vrana’s approach is to stand up a clean production environment rather than battle for weeks on a compromised one.

The pattern he describes:

• Switch the target environment via GitLab by changing the AWS account.
• Deploy services anew and create a fresh production environment.
• Restore from database backups.
• Go live again, then investigate what happened.

Key rules underpinning this capability:

• Test this process regularly—documentation alone doesn’t count.
• Keep backups in separate accounts—if the main account is attacked, backups must survive.
• Never hard‑code AWS resources—flexibility to swap accounts must be built‑in.
• Aim to simply change the AWS account ID in GitLab and spin up services again; the infrastructure should “rewire” on demand.

There will always be some manual steps—loading large database dumps, verifying the application—but recovery should be measured in hours or days, not weeks. In a volatile environment, this ability is strategic.

5) Eliminate the “rats”: manage technical debt and code quality

By “Elimination of rats,” Vrana means relentless care for quality and technical debt. He references SonarQube, a static analysis tool that identifies code issues and quality warnings. The metaphor is a card house: with a weak foundation, a single flick can collapse the entire structure.

Actionably, treat warnings as work in progress and close them frequently. Regular, incremental debt reduction preserves change velocity and reduces the blast radius of releases.

6) Small, frequent releases: follow INVEST, shorten time‑to‑done, reduce risk

Small, frequent pushes to production are central to Vrana’s approach. He references INVEST criteria for writing user stories and aims to reduce the time from “to do” to “done.” Because:

• There’s no value in a feature the customer cannot use now.
• Bundling 20 features into one push makes debugging painful. Sequential, single‑feature deployments simplify fault isolation.

Directionally, this keeps value flowing continuously, avoids big‑bang risk, and improves the learning cadence.

7) Transparency dispels myth: track KPIs and costs

Without metrics, you’re guessing. Vrana emphasizes:

• Track how many transactions your system processes.
• Track the cost of each transaction.
• Track other relevant KPIs.

The payoff is twofold: drive costs down and enable scaling. When unit costs drop, higher volumes become feasible, and customers benefit from lower prices for the same service.

8) Operational excellence: don’t let customers find bugs

Proactive operations are non‑negotiable:

• Measure data quality and latency continuously.
• Track invocations and errors.
• Get notified about errors and delays—these are early warning signals.
• React to anomalies: when average traffic jumps from 1,000 req/min to 10–20k, find out why (e.g., a DDoS or other event).

The idea is simple: you should know something is wrong before your customers do.

9) Continuous improvement: next month should be better than last month

Vrana makes a commitment to self‑improvement. Tactics include:

• The Boy Scout Rule: leave the code cleaner than you found it; apply small refactors when you’re there anyway.
• Write testable, high‑quality code—ambitious, but directional.
• At Sportradar, the team allocates 30% of each sprint to improving quality—an explicit investment.
• Eliminate toil: anything manual, repetitive, and automatable should be automated. Example: a report that takes one hour, five times per week (five hours/week). If automation costs 20 hours to build, breakeven arrives in four weeks—and it saves time thereafter.

10) “If it’s not tested, it’s broken”: verify, don’t assume

Vrana’s favorite rule is uncompromising:

Targets and practices he highlights:

• Aim for about 80% test coverage (not a hard rule, but a worthwhile goal).
• Run smoke and regression tests on every push.
• Include infrastructure tests, integration tests, and system tests. Without verification, assume it’s broken.

The mantra turns testing from a bolt‑on into a first‑class engineering discipline.

Putting the North Star to work: practical starting points

Translating the ten guidelines into day‑to‑day engineering means committing to routine actions. Based strictly on the session, here are concrete cues to get started:

• Make the North Star explicit: agree on the decision direction (e.g., “customer value first,” “availability before feature count”). The compass must be visible in daily trade‑offs.
• Elevate NFRs: define availability targets, latency budgets, load assumptions, and scaling behaviors; measure and prioritize them explicitly.
• Ensure cross‑functional capability: assemble teams with design, architecture, development, and QA so they can operate end‑to‑end without brittle hand‑offs.
• Live ownership: “you build it, you ship it, you support it” needs both tool support and mindset—pipelines and alerting help, but the team’s stance is decisive.
• Exercise the hostage playbook: routinely rehearse fresh‑account recovery. Store backups in separate accounts. Never hard‑code resources. Design for swapping the AWS account ID in GitLab and redeploying quickly.
• Integrate quality into flow: surface SonarQube warnings and close them. Reduce debt in small, steady increments.
• Increase release cadence: prefer small, frequent deployments. Avoid large batches to simplify debugging and keep customer value flowing.
• Track KPIs: measure transactions and cost per transaction; use trends to both scale and improve price‑performance.
• Treat operational signals as first‑class: monitor latency, data quality, errors, invocations, and anomalies; react to alerts before customers notice.
• Reserve improvement capacity: dedicate explicit time (like the cited 30%) for refactoring, testability, and toil elimination—continuously, not ad hoc.
• Enforce a test strategy: aim around 80% coverage; run smoke/regression on each push; include infrastructure, integration, and system tests. Default to “broken until proven otherwise.”

Technical implications: architecture and process aligned to direction

Architecturally and organizationally, these guidelines imply a few non‑negotiables:

• Design for account flexibility: if swapping cloud accounts is part of the resilience plan, hard‑coded resources are off‑limits; configuration must be dynamic.
• Make deployments routine: small, frequent releases require automated quality checks (smoke/regression) and reliable rollout mechanics. If the team owns production, it also owns telemetry and alerting.
• Treat scalability as a deliverable: load behavior and latency are product features. Testing and monitoring for availability and spike resilience are first‑order goals.
• Govern by data: transactions and cost per transaction are product metrics, not just finance artifacts. Visible KPIs replace gut feel with actionable insight.
• Manage debt continuously: either debt compounds or it’s paid down. Frequent, small pay‑downs protect delivery speed and stability.

Memorable lines worth carrying forward

From “North Star Direction” by Gerald Vrana (Sportradar Media Services GmbH), a few concise lines stand out:

• “It will not show the way, but it will guide you.” — Direction over detailed maps.
• “It only counts when the customer uses it. Done is not always done.” — Production and adoption define value.
• “If it’s not tested, it’s broken.” — Verification over assumption.

These aren’t slogans; they’re operating principles.

Closing: Aiming for direction to deliver value

“North Star Direction” is a compact, practice‑oriented blueprint for teams shipping into uncertainty. Vrana’s ten guidelines emphasize:

• Customer obsession with NFRs at the top.
• Cross‑functional, end‑to‑end teams that own what they ship.
• Hostage‑scenario recovery via account swaps, separate backups, and no hard‑coded resources.
• Continuous quality through debt reduction, small releases, KPI transparency, and operational excellence.
• A testing stance that treats unverified code as broken by default.

In our DevJobs.at view, that’s the power of a North Star in a VUCA world: it reduces decision friction and keeps teams focused on outcomes—robust systems that deliver customer value, on time, under real‑world conditions.