Dackota Johnson

Platform Engineering Lead · Mesa, AZ · Remote

I build the platforms organizations ship on — ten-plus years of GitOps delivery, Kubernetes at scale, and multi-tenant reliability. Most recently led the platform team behind Panasonic's enterprise agentic-AI platform.

# career.pipelineTrunk-based. Single artifact. Promoted through every stage.

One engineer, promoted stage to stage since 2015 — the same way I ship software. Select a stage to inspect it, or hit Promote to walk the pipeline.

freight: dackota@sha-2015 · verified in all upstream stages
✓ Synced✓ Healthy Platform Engineering Lead — Panasonic Global Applied AI (GAAI, formerly Yohana / Panasonic Well), Remote · Jun 2022 → Jul 2026

Ran the company-wide Kubernetes platform every product team deployed on — ~30 engineers building KanpAI, Panasonic's enterprise agentic-AI platform: 20+ production agents across 10+ business units in the US and Japan. Led the 4-person platform team: roadmap, priorities, mentoring, and the platform's voice to engineering leadership.

  • Delivery Replaced Spinnaker with a self-service GitOps platform on ArgoCD + Argo Workflows/Events — pipelines from one command, setup 6 hrs → 10 min, lead time 1 hr → 15 min, scaled 15 → 228 microservices
  • Promotion Drove trunk-based single-artifact promotion with Kargo across 5 teams / 16 services — weekly deploys became 15 a day, one click dev-to-prod
  • Charts Built helm-generic-app: schema-validated, secure-by-default, CI-tested — new-service packaging 3 hrs → 5 min across 16 microservices
  • Tenancy Cut tenant onboarding from 7 days of manual Vault + Terraform to minutes with a git push — bootstrap chart, External Secrets, ACK controllers
  • Reliability Zero customer-impacting incidents in GAAI's first 10 months — PodDisruptionBudgets, graceful drain, Karpenter-rolled EKS upgrades from a single Terraform PR
  • Security Multi-tenant isolation with Kyverno policy-as-code, default-deny NetworkPolicies, per-tenant gateways — then built a production-identical red-team environment in 3 hrs and fixed what it found
  • Recovery Verified end-to-end restore drills with Velero + CSI snapshots and cross-region failover; moved 30 Datadog monitors into GitOps
  • Migration Drove the platform's carve-out onto its own AWS foundation — a dozen-plus microservices moved ahead of the corporate deadline, zero data loss
  • AI tooling Shipped claude-projects: Claude Code subagents with guardrail hooks running 2–3 parallel epics — release automation, Renovate, ECR publish, a change-tracking dashboard
  • Teaching Led a 3-week on-site SRE workshop in Japan — 20 engineers from 12 Panasonic subsidiaries: SLOs, error budgets, incident response, CI/CD

# platform.metricsNumbers a dashboard would page you about — in a good way

0microservices on the delivery platform (up from 15)
0deployments per day, org-wide
0dev-to-prod lead time
0pipeline setup for a new service
0customer-impacting incidents in GAAI's first 10 months
0infrastructure cost cut migrating VMs → Kubernetes
0mean incident triage time
0run with one cluster's worth of effort
0production AI agents across 10+ business units

# kubectl.execYou have shell access. Poke around.

A resume you can query. Try help, kubectl get jobs, argocd app sync career, trace, or sudo hire dackota.

dackota@me:~ — read-only cluster, generous RBAC

↑/↓ history · clear to reset · everything is fair game

# otel.traceYour visit, as a distributed trace

This page is instrumented like a service I'd run in production. Every section you read, every stage you click, every command you type opens a span — with real durations, attributes, and status codes. Select a span to inspect it.

trace explorer — head sampling 100%
trace id lives in memory only and dies with the tab — visitor.id is a first-party cookie kept ~1 year to correlate page-view spans across visits

# slo.dashboardThis session has an SLO. Here's how it's doing.

The same thing I taught 20 engineers in Japan, pointed at this page: an objective, an indicator measured from real spans, and an error budget that burns when the page fails you.

SLO · 99.9% of interactions complete within their latency objective measuring…
good 0 total 0 SLI — error budget left 100%

Every instrumented interaction carries a latency objective — 50 ms for a pipeline stage click or a freight promotion, 100 ms for a shell command. Animations and dwell time don't count, because neither is a request. A span that misses its objective, or exits non-zero, burns budget. Go break it: rm -rf / in the shell above gets denied by policy, and a denied request is still a failed request.

Real user monitoring — your actual Core Web Vitals

LCP—largest contentful paint · good ≤ 2.5s
INP—interaction to next paint · good ≤ 200ms
CLS—cumulative layout shift · good ≤ 0.1
TTFB—time to first byte · good ≤ 800ms

Delivery performance — DORA, computed live from this site's own repo

Not a claim: your browser calls the GitHub API for this repository's releases and commits and does the math on the spot. Definitions are printed with the numbers, because a DORA metric without its definition is a vanity metric.

— deployment frequency releases published ÷ weeks observed
— lead time for changes median commit authored → first release containing it
— change failure rate releases followed by a revert ÷ releases
— time to restore median broken release → the release that fixed it

querying api.github.com/repos/dackota/resume-website …

# changes.feedThe platform I run when nobody is paying me

Live from changes.dackota.com — a Go service I wrote that polls my config repos, extracts tracked values, and classifies every change by impact and risk. Below is what it has actually seen: real commits, real version deltas, no screenshots. Chart and Terraform changes will show you their blast radius — what the bump did to the rendered manifests, or which resources it would replace.

— of changes opened and merged by automation Renovate and release-please, unattended
— changesets ingested in the window every tracked-value change, not every commit
— changes per day across the platform mean across the window loaded
— repositories under change tracking charts, clusters, and this site
30 days of change, colored by the highest impact that day majorminorpatchother
30 days agotoday

Pick a day to re-query the feed against that exact half-open window (since inclusive, asOf exclusive) — the same tiling the API's polling recipe uses.

impact
    querying the change feed…

    # CHANGELOG.mdReleased with conventional commits since 2015

    1. v4.0.02025

      feat!: became the platform team's lead — roadmap, priorities, mentoring, and the platform's voice to leadership. BREAKING CHANGE: carve-out from Panasonic Well onto GAAI's own AWS foundation, a dozen-plus microservices moved with zero data loss.

    2. v3.0.02022

      feat!: joined Panasonic's first forward-deployed AI engineering team. Two generations of continuous delivery shipped; the release model set here is how the rest of the org ships.

    3. v2.0.02018

      feat!: promoted to SRE. Immutable infrastructure, the VM-to-Kubernetes migration, and a taste for deleting toil that never went away.

    4. v1.0.02015

      feat: initial release — sysadmin at Infusionsoft. Three OS fleets, scripted provisioning, and the discovery that everything is better automated.