Tech Culture Guide

This guide captures the practices and tools that shape how we build software at AdAction. It reads along two axes:

Three value pillars — every practice serves at least one of Continuous Learning, Ownership, or Hustle. These come from our Tech Culture Miro board, where you can explore them as a Venn diagram. Each practice below is tagged with the pillar(s) it serves. One clarification worth stating up front: Hustle means flow, not busyness. We care that work moves quickly through the system, not that every engineer is occupied every minute.
Four adoption tiers — how we organize this guide. Each practice sits in one tier based on how settled it is here today:
- Engineering Table Stakes — practices any engineer worth their salt should be doing today.
- AdAction Standards — may be more debatable in the broader tech community, but we embrace them, have implemented them, and expect engineers to keep practicing them.
- Aspirationals — things we believe in and want, but that are still ahead of conditions on the ground today.
- Anti-Patterns — things we've decided to actively move away from.

Tiers reflect where a practice stands now, not its importance — an aspiration today can become a standard tomorrow, and a standard can become an anti-pattern once we learn better.

At a glance

The three pillars, in short:

Pillar	What it means
Continuous Learning	Always growing
Ownership	Accountable end-to-end
Hustle	Delivering value quickly

The tiers aren't a ranking, they're a timeline. Three of them form a graduation path, and a practice moves along it as the conditions around it change. The fourth sits off the path: Anti-Patterns is where something lands when we decide to move away from it, not a further step along the line.

So the tier a practice sits in today tells you how settled it is, not how much it matters.

The guide below is ordered most settled first, so you can start with what's expected of you today and read toward where we're heading, with the practices we're retiring at the end.

Engineering Table Stakes

Practices and tools any engineer worth their salt should be doing today.

Continuous Integration (CI) — Continuous Learning · Ownership
Auto build/test on each commit to catch issues early. (Fowler)
PR Reviews — Continuous Learning · Ownership
A timely, focused exchange that spreads context across the team. Reviewing is as much a part of the job as authoring: keep turnaround short, aim to unblock the author, and expect to learn something yourself. (Google Code Review Developer Guide)
Test Automation — Ownership · Hustle
Unit, integration, and E2E tests for fast feedback and safe refactoring. (Test Pyramid)
Static Analysis — Ownership
Automated code checks for bugs, security, and style pre-production. (OWASP)
Repository Maintenance — Ownership
Dependencies, docs, dead code, and builds kept healthy. (Technical Debt)
Refactoring — Continuous Learning · Ownership
Improve internal design without changing behavior. (refactoring.com)
Observability — Continuous Learning · Ownership
Logs, metrics, and traces enable deep system understanding. (Charity Majors)
Mentorship — Continuous Learning
Pairing juniors with seniors for technical, career, and org guidance. (Mentorship)
Conferences — Continuous Learning
Industry events to learn, share, and network. (confs.tech)

AdAction Standards

Practices and tools that may be more debatable in the broader tech community, but which we embrace, have implemented, and expect engineers to continue to practice.

Code for Today (YAGNI) — Hustle
Avoid over-engineering; build only what's needed now. (YAGNI)
Postmortem Reviews — Continuous Learning · Ownership
Blameless incident analyses to learn, document, and prevent recurrences. (Etsy)
Incident Management — Ownership · Hustle
Detect, respond, and resolve with on-call, escalation, and comms. (PagerDuty)
Continuous Delivery — Continuous Learning · Ownership · Hustle
Keep code always deployable and automate safe, on-demand releases; SDK updates ship reliably without disrupting apps. (Fowler)
Move Fast with Confidence — Continuous Learning · Ownership · Hustle
Ship quickly without trading off quality by leveraging strong tests, observability, and fast rollback. (Self-Testing Code)
Closed-Loop Feedback — Continuous Learning · Ownership · Hustle
A structured cycle of listen → decide → ship → validate → share → improve. (Lean Startup)
Trunk-based Development — Hustle
Commit to main frequently; use flags to hide incomplete work. (trunkbaseddevelopment.com)
Semantic Release — Ownership · Hustle
Automated versioning from commit conventions for clear SDK changes. (semantic-release)
DORA Metrics — Ownership · Hustle
Deployment frequency, lead time, change failure rate, MTTR. (dora.dev)
Architecture Decision Records (ADR) — Ownership
Lightweight docs capturing key decisions and rationale. (Nygard). See our own ADR template and Architecture Decision Records.
Service Level Objectives (SLO) — Ownership
Clear reliability targets creating shared performance language. (Google SRE)
Feature Flags & A/B Testing — Continuous Learning · Hustle
Control rollout and compare variants for safe, measurable impact. (Fowler)
Work in Small Batches — Hustle
Deliver tiny, independently mergeable increments for faster feedback. If a slice can stand on its own, land it rather than holding it back for a bigger batch. (DORA)
Ship Fast, Ship Often — Hustle
Prefer small, frequent releases for lower risk and faster feedback. (Release early, release often)
Short Cycle Times — Hustle
Minimize idea-to-production time to react to market and publisher needs. (DORA — Four Keys)
Limit Work In Progress (WIP) — Hustle
Constrain concurrent tasks to improve flow and reveal bottlenecks. Unlanded changes count: a branch waiting on review is WIP. Building on top of one is reasonable when each layer lands as it's ready; what we want to avoid is a pile of work sitting behind a review that's stalled, which hides the bottleneck rather than surfacing it. (Kanban WIP limits)
Lean Management — Ownership · Hustle
Eliminate waste, optimize flow, and improve continuously. (Lean principles)
Infrastructure as Code (IaC) — Continuous Learning · Ownership
Version-controlled infra for reproducible, auditable changes. (ThoughtWorks)
Team Health Checks — Continuous Learning
Regular self-assessments of effectiveness, morale, and practices to surface improvements early. (Spotify Squad Health Check)
Bookclub — Continuous Learning
Structured reading and discussion to build shared knowledge and vocabulary. (Book club)
Business Partnership — Ownership
Engage stakeholders to align tech choices with revenue and publisher outcomes. (Business/IT alignment)
Pair/Mob Programming — Continuous Learning · Hustle
Two or more engineers collaborate at one station for rapid feedback. (Tuple guide)

Aspirationals

Tools and practices we believe in and would like to do, but which are still ahead of the conditions on the ground today.

AI Agentic Coding — Continuous Learning · Ownership · Hustle
Delegate well-scoped engineering work (planning, implementation, review, refactoring, investigation) to AI coding agents, while the engineer stays accountable for the result: steering the work, reviewing output, verifying behavior, and owning what ships. (Anthropic)
Ship / Show / Ask — Continuous Learning · Ownership
The author picks the ceremony each change deserves: Ship merges straight to main, Show opens a PR and merges immediately with review landing after, and Ask waits for discussion. This buys signal, not speed: when everything needs an approval, an approval tells you nothing. It's also less of a leap than it sounds, since our one repo that requires no approvals still gets reviewed on over 90% of changes. Aspirational because it isn't rolled out, not because we're undecided, and we'll move as fast as each repo's CI allows. And when review latency is the thing pushing us toward long-lived branches, this is the fix we want to reach for first. (Ship / Show / Ask)
devcontainers — Continuous Learning · Ownership
Standardized containerized dev environments. (VS Code)
Test-Driven Development (TDD) — Continuous Learning · Ownership
Write tests first to drive design and coverage. (Fowler)
Data as a Product — Continuous Learning · Ownership
Own, document, and roadmap internal data with quality standards. (Data Mesh)
Data Democracy — Continuous Learning · Ownership
Broad, governed data access so all teams make data-informed decisions. (Bernard Marr)
Refactoring Club — Continuous Learning
Collaborative sessions improving code structure without behavior changes for maintainability. (Coding Dojo)
Certifications — Continuous Learning
Vendor/industry credentials (e.g., AWS, GCP, Scrum) to validate and grow skills. (AWS Certification)
Outcome Ownership — Ownership
We care about the impact of a launch or rollout. Every initiative should have a goal, an owner, and a success metric (when applicable). (Outcome Oriented)
Customer Empathy Sessions — Continuous Learning
Listening to feedback is a core part of building great products. "Customers" can mean stakeholders both external and internal. As a team, we stay close to user signals (tickets, calls, recordings, meetings, etc.). (Empathy Mapping)
DevOps Culture — Ownership
You build it, you run it; platform teams provide shared tooling. (Vogels, Team Topologies)

Anti-Patterns

Practices we've done, seen, or been tempted by, and have decided to actively move away from. This tier works like the "Caution" ring on the Thoughtworks Technology Radar: it isn't a list of mistakes to feel bad about, it's a shared signal that we learned something and would rather not repeat it.

Where the tiers above tag the pillars a practice serves, these note the pillar the practice undermines.

Running Production off a Laptop — Undermines Ownership
Scheduled jobs, pipelines, or agents that the business depends on, running from someone's personal machine. There's no source of truth, no observability, no on-call, and the whole thing disappears when that person does. Local runs for your own productivity are fine; once anything else depends on the output, it gets productionized. (Snowflake Server)
Orphaned Experiments — Undermines Ownership
A prototype quietly picks up real users and real dependencies without anyone signing up to maintain it. The answer isn't to stop experimenting, it's to make the transition deliberate: an experiment either gets an owner and a home, or it gets turned off. (Shadow IT)
Hand-Rolled Data Pipelines — Undermines Ownership · Hustle
Bespoke scripts moving and transforming data when the work already fits our stack. We give up lineage, testing, and documentation, and we lose the intermediate tables other teams could have reused. If it reads from the warehouse and writes back to it, it belongs in dbt behind a DAG. (dbt)
Data Files in Git — Undermines Ownership
Committing generated data so a deploy can pick it up. Git keeps it forever, every clone gets slower for everyone, and the data still isn't versioned in a way that helps anyone. Put it in object storage or a table and let the pipeline read it. (Large files on GitHub)
Cron-Only Scheduling — Undermines Ownership
Chaining jobs by wall-clock time and hoping the upstream one finished. When it doesn't, we get stale or partial results and usually find out from a stakeholder. Prefer data-aware scheduling that triggers on the upstream dataset actually landing. (Airflow data-aware scheduling)
Arbitrary Estimation — Undermines Continuous Learning · Hustle
Points or dates produced to satisfy a process rather than to inform a decision. They manufacture false precision and consume time we could spend slicing the work smaller. Estimate when it changes what we do, and otherwise lean on small batches and short cycle times. (Fowler)
Review as a Mandatory Gate — Undermines Continuous Learning · Ownership
Requiring an approval on every change regardless of risk, especially where the automated checks behind it are thin. A repo that demands a human sign-off but doesn't require its own tests to pass has made the weakest gate the only gate, and approval decays into a rubber stamp. It shows up after approval too, when a cleared change sits unmerged because landing it is nobody's job. A team that values review keeps reviewing once the mandate goes away, so the mandate mostly buys ceremony, not scrutiny. Put the enforcement in CI and match review ceremony to risk. If a change really does need a second signature, that's a property of that change, not a reason to gate every change. (Ship / Show / Ask)

In Closing

Our culture rests on Continuous Learning, Ownership, and Hustle — always growing, accountable end-to-end, and delivering value quickly.

At a glance​

Engineering Table Stakes​

AdAction Standards​

Aspirationals​

Anti-Patterns​

Suggested Readings​

In Closing​