Skip to main content

Engineering Standardization — Executive Brief

Engineering Standardization Recommendation

The situation​

We are adding developers and weighing two big consolidations — GCP → Azure and GitHub → Azure DevOps — with no written standard for how we build, track, document, or secure software. Today almost every process resolves to "one engineer knows it." That is our single biggest risk as the team grows.

The finding​

The capability already exists and works — it's just undocumented, unenforced, and centralized. We already run one Azure DevOps org, a modern Python toolchain, an auto-deploying docs site, a code-validated knowledge base, reusable AI agents, an overnight AI development pipeline, and (as of this week) a company Azure cost/access governance standard. The gap is the connective tissue: a declared standard, a template that makes the standard the easy path, and an owner besides the founder-engineer.

The recommendation​

Adopt one company standard across eight domains — (A) ADO repos/branching/boards, (B) dev environment + a thin everyday CLI, (C) documentation, (D) AI/agentic workflows, (E) access & resource governance, (F) third-party contractor onboarding, (G) cloud/SCM migration, (H) API development & testing. Each is an opinionated default grounded in what already works, with explicit decision points for the PO. No rewrite is required — the cost is documentation, enforcement, and one round of migrations.

The three decisions that matter most​

  1. GitHub → Azure DevOps: recommend GO. Consolidate to one source-control and identity plane. Migrate the low-risk repos now; migrate the mars product after its Aug-15 go-live. (Decide by Day 30.)
  2. GCP → Azure: decide, don't presume. Run the invoice/OCR stack's real 30-day bill and a proof-of-concept of Azure's OCR before committing — the OCR service is the one piece with no clean Azure equivalent. (Decide by ~Day 45.)
  3. Distribute authority. Give the incoming PO read access to Azure and name a second approver, so reviews and grants no longer bottleneck on one person.

What the Product Owner gets on day one​

  • A ratification checklist of ~18 pre-analyzed decisions (accept the default or amend).
  • A 30/60/90-day plan and a 7-phase rollout that sequences everything, with dependencies and hard dates.
  • A RACI and a 12-metric scorecard (e.g. onboard a developer in < 1 day → < 4 hrs; 100% of repos on-standard; migration status tracked).

The ask​

Ratify the standards, name the standards owner, and set the two migration decision dates. Foundation work can start the day it's signed — it does not depend on the migration decisions. Full detail and the eight domain chapters are in the accompanying recommendation package.