Technical Leadership Best Practices

Database council for cross-team schema changes. Use this list when establishing or auditing data platform leadership.

How to Use This List

Adopt council cadence before the second team shares one database.
Score each service quarterly against connection, migration, and review items.
Publish decisions as ADRs in git, not meeting notes only.
Pair list with error budget and incident post-mortem actions.

A - Governance

Database council meets weekly with migration queue. Cross-team conflicts surface early.
Single schema style guide enforced in CI. Naming, FK policy, RLS patterns documented.
Schema changes treated as API semver. Breaking changes use expand/contract.
ADR required for shared-table ownership disputes. Who writes, who migrates.

B - Quality Bar

Query review standards mandatory above QPS threshold. EXPLAIN evidence in PR.
Index requests flow through measured approval. No ad hoc production CREATE INDEX.
pg_stat_statements reviewed weekly. Top ten by total time has owner.
MVCC training for every new service team. Within 30 days of first deploy.

C - Reliability Partnership

Tech lead co-owns datastore SLO with SRE. RPO/RTO explicit in status docs.
On-call runbooks linked from service README. Disk, locks, lag scenarios.
Post-incident actions tracked to completion. Same sprint as post-mortem.
Maintenance windows coordinated with product calendar. Blackout dates shared.

D - Cost and Growth

Storage growth forecast shared with finance monthly. Tie to retention and indexes.
Replica count justified by read SLO. Not "default 2" without load proof.
Right-sizing review quarterly. Instance generation and IOPS match working set.
Retire unused indexes and schemas. idx_scan monitoring with drop policy.

FAQs

How big should database council be?

One delegate per consuming service plus DBA chair; keep under 10 people for decisions.

What if teams resist council?

Tech lead escalates via incident cost and SLO misses; start advisory then mandate after Sev-2.

Does council block delivery?

Goal is parallel-safe migration ordering, not veto power for velocity.

How to handle acquired company schema?

Council adds integration track; separate ADR for merge vs federated databases.

Should tech lead write SQL?

Yes for standards and reviews; delegate deep tuning to staff DBA.

How to measure leadership impact?

Incident frequency, migration failure rate, mean time to approve safe schema change.

What about polyglot persistence?

Council scope clarifies Postgres vs other stores per bounded context.

AI-generated schema in council?

Same review bar; generated DDL is not auto-approved.

Remote-first council tips?

Async migration doc 24h before; live only for conflicts and incidents.

What should I read next?

See Tech Lead Basics on Postgres.

Tech Lead Basics on Postgres - correctness/uptime/cost
Query Review Standards - PR bar
Governance Basics - org standards
Working with Engineering Best Practices - stakeholder alignment
Change Management Best Practices - DDL safety

Stack versions: This page was written for PostgreSQL 18.4 (stable 18, maintenance 17), pgvector 0.8+, PgBouncer 1.x, Patroni 3.x, and PostGIS 3.5+.

Technical Leadership Best Practices

Database council for cross-team schema changes. Use this list when establishing or auditing data platform leadership.

How to Use This List

Adopt council cadence before the second team shares one database.
Score each service quarterly against connection, migration, and review items.
Publish decisions as ADRs in git, not meeting notes only.
Pair list with error budget and incident post-mortem actions.

A - Governance

Database council meets weekly with migration queue. Cross-team conflicts surface early.
Single schema style guide enforced in CI. Naming, FK policy, RLS patterns documented.
Schema changes treated as API semver. Breaking changes use expand/contract.
ADR required for shared-table ownership disputes. Who writes, who migrates.

B - Quality Bar

Query review standards mandatory above QPS threshold. EXPLAIN evidence in PR.
Index requests flow through measured approval. No ad hoc production CREATE INDEX.
pg_stat_statements reviewed weekly. Top ten by total time has owner.
MVCC training for every new service team. Within 30 days of first deploy.

C - Reliability Partnership

Tech lead co-owns datastore SLO with SRE. RPO/RTO explicit in status docs.
On-call runbooks linked from service README. Disk, locks, lag scenarios.
Post-incident actions tracked to completion. Same sprint as post-mortem.
Maintenance windows coordinated with product calendar. Blackout dates shared.

D - Cost and Growth

Storage growth forecast shared with finance monthly. Tie to retention and indexes.
Replica count justified by read SLO. Not "default 2" without load proof.
Right-sizing review quarterly. Instance generation and IOPS match working set.
Retire unused indexes and schemas. idx_scan monitoring with drop policy.

FAQs

How big should database council be?

One delegate per consuming service plus DBA chair; keep under 10 people for decisions.

What if teams resist council?

Tech lead escalates via incident cost and SLO misses; start advisory then mandate after Sev-2.

Does council block delivery?

Goal is parallel-safe migration ordering, not veto power for velocity.

How to handle acquired company schema?

Council adds integration track; separate ADR for merge vs federated databases.

Should tech lead write SQL?

Yes for standards and reviews; delegate deep tuning to staff DBA.

How to measure leadership impact?

Incident frequency, migration failure rate, mean time to approve safe schema change.

What about polyglot persistence?

Council scope clarifies Postgres vs other stores per bounded context.

AI-generated schema in council?

Same review bar; generated DDL is not auto-approved.

Remote-first council tips?

Async migration doc 24h before; live only for conflicts and incidents.

What should I read next?

See Tech Lead Basics on Postgres.

Tech Lead Basics on Postgres - correctness/uptime/cost
Query Review Standards - PR bar
Governance Basics - org standards
Working with Engineering Best Practices - stakeholder alignment
Change Management Best Practices - DDL safety

Stack versions: This page was written for PostgreSQL 18.4 (stable 18, maintenance 17), pgvector 0.8+, PgBouncer 1.x, Patroni 3.x, and PostGIS 3.5+.

Technical Leadership Best Practices

Search Documentation

Technical Leadership Best Practices