Team Operating Model

Engineering exists to make Maryland’s digital services easier to use, easier to operate, and cheaper to sustain. Read this first when joining the team: it explains how we think about the work, how we collaborate, and what “good” looks like as a project matures.

How we work together

We work in public, durable artifacts. Plans, pull requests, ADRs, runbooks, and repo documentation carry the work forward so decisions do not live only in meetings, chat threads, or one person’s memory.

1. Start with the real user, operator, agency goal, and success measure.
2. Keep work small enough to review, ship, observe, and roll back.
3. Reuse proven components, platform paths, and libraries before inventing a custom solution.
4. Make the responsible path the easy path with clear docs, templates, CI, review gates, and automation wherever possible.
5. Own trust end to end: accessibility, security, reliability, compliance, and operational handoff are part of the work.

Engineering philosophies

1. Think carefully before building a new service or app. A service or app is a contract with users, operators, and future maintainers; create one only when we can honor that promise.
2. Prefer fewer systems with clearer ownership. Boring shared paths beat clever one-offs that nobody can support.
3. Treat simplicity as a feature. The best solution is often the smallest thing that solves the real problem and leaves room to change direction.
4. Build for rollback, repair, and replacement. Every system should have a way back, a way to diagnose failure, and a path to evolve without drama.
5. Let evidence beat confidence. Tests, logs, user feedback, accessibility checks, security scans, and operational data matter more than how certain we feel.

Collaboration norms

Good engineering work here is not isolated hero work. It is planned, reviewed, documented, and coordinated with the people who will use, operate, approve, or inherit the system.

1. Write down the problem before proposing the implementation.
2. Name assumptions, constraints, and tradeoffs early.
3. Bring Design, Product, Web Experience, Strategic Investments, or vendor partners in before their part of the work is already decided.
4. Keep the pull request focused enough that a reviewer can understand both the intent and the risk.
5. Treat review as shared ownership, not a final obstacle before merge.

Maturity expectations

Projects move through four maturity modes. Each mode has a different job, so the engineering bar changes with the risk: a proof of concept should prove the idea quickly, while production should be safe to operate, audit, and improve.

Mode	What you should do here	What does not need to be true yet
Proof of concept	Test whether the idea, integration, workflow, or technical approach is viable. Keep the code disposable, narrow, and honest about shortcuts.	It does not need production readiness, full automation, complete observability, or polished UX.
Pilot	Put the idea in front of a small real audience with explicit support and rollback expectations. Add enough reliability, accessibility, data handling, and docs to learn safely.	It does not need full scale, complete self-service, or every production control fully automated.
Pre-production	Remove known launch blockers, harden the system, rehearse operations, and prove the path to release. CI, security, observability, ownership, and runbooks should be credible.	It does not need perfect optimization, but remaining gaps must be known, owned, and time-bound.
Production	Operate the service as a durable public commitment. Keep delivery, monitoring, incident response, security, accessibility, compliance evidence, and documentation current.	It cannot rely on hero support, undocumented manual steps, or unowned risk.

Review questions

Use these questions when planning or reviewing work.

1. Does the plan explain why this work matters, not only what will change?
2. Is the change small enough to deploy, verify, and roll back independently?
3. What existing pattern, component, or platform path did we consider first?
4. Would another engineer understand this decision without a meeting?
5. Could the change weaken user trust, operational safety, or compliance posture?

Where to go next

1. 01 — Shipping Work — how a change moves from plan to production
2. 02 — Ownership and Systems — who owns decisions, repos, vendors, and delivery paths
3. ADR-024 — Engineering Standards — binding engineering floor