Joey King

Open to opportunities to lead technical initiatives and improve business operations.

From complex problems to working systems.

I’m Joey King, a software engineer with experience building internal platforms, automating workflows, and taking technical projects from investigation through production support. My responsibilities have grown to include shaping scope, coordinating with other teams, making release decisions, and helping people adopt what we build.

I enjoy understanding how work gets done and finding practical ways to improve it. Building the solution is rewarding; seeing how people use it, helping them work through problems, and figuring out what to change next are just as interesting to me. When guiding interns, I walked them through investigations and helped them learn how to find answers independently.

See selected workjoey@joeylking.com

How complex work comes together

Technical work involves decisions about people, processes, and the systems supporting them. Here are some of the questions I consider along the way, with examples from projects I’ve owned or helped deliver.

PeopleWho feels the problemWho owns the decisionStakeholders and reviewersContributors and mentoringSupport and handoffFeedback from users
ProcessHow the work runs todayScope, risks, success measuresDependencies and responsibilitiesReview and validationRollout and rollbackWhat to change next
TechnologySystems already involvedOptions and their costsInterfaces and contractsWorking softwareRelease and monitoringRecords and measures
  1. 01 / 06

    Understand

    Find the operational problem behind the requested feature.

    In the workAutomation audit & retention platform

    After an incident exposed a gap in execution history, I investigated the problem with the analytics team and prospective users, then proposed a shared audit service.

  2. 02 / 06

    Decide

    Choose a scope that addresses the problem within the constraints.

    In the workGoverned vulnerability remediation

    For an eight-week prototype, I removed AI from the scope when its approval process remained unclear. We delivered a narrower workflow that prepared dependency updates for human review.

  3. 03 / 06

    Coordinate

    Make dependencies, responsibilities, and decisions clear.

    In the workLegacy platform modernization

    I coordinated phased releases with the teams using the API. They validated one or two endpoints at a time while the legacy implementation remained available, and I made the release or rollback decisions.

  4. 04 / 06

    Build

    Build the system and make it practical for others to use.

    In the workAutomation audit & retention platform

    I built the audit service and reusable Spring Boot, Go, and C# integrations. Teams could use the API, publish events to Kafka, or adopt an integration that recorded application requests.

  5. 05 / 06

    Launch

    Prepare validation, rollout, rollback, documentation, and support.

    In the workLegacy platform modernization

    When a release reproduced an existing timeout, I rolled it back, traced the problem to unnecessary SQL joins, and released the fix a few days later.

  6. 06 / 06

    Learn

    Use what happens in practice to improve the system and the way we deliver it.

    In the workAutomation audit & retention platform

    A downstream data-routing issue delayed the audit interface. It showed me the importance of earlier validation across the full production path and closer checkpoints with teams owning critical dependencies.

Selected work

These projects show different parts of my work: building shared services, making delivery decisions, helping teams adopt tools, and leading a prototype within tight constraints.

Production

Automation audit & retention platform

Problem
An automation incident exposed a gap: the logs needed to reconstruct what happened had already expired. Teams needed a durable, consistent execution history.
My role
Owned the service from initial research and design through architecture review, implementation, release, and support. I also built reusable integrations, supported adopting teams, and later added retrieval APIs and a user interface.
Key decision
Used a common event schema with room for team-specific context, multiple integration options, and an existing analytics pipeline for long-term retention.
Outcome
By May 2026, approximately four teams and ten automation applications had integrated. The platform supported seven-year retention through infrastructure owned by the analytics team.
Read the case study

PrototypeFirst place in an internal innovation competition

Governed vulnerability remediation

Problem
Routine vulnerability remediation was consuming engineering time that could otherwise go toward product and platform improvements.
My role
Proposed the project, formed and led a three-person team, set the scope, and built the Go prototype except for a teammate’s mock findings service. Our third teammate contributed research and presentation support.
Key decision
Limited automation to dependency updates with a known fixed version. High and critical findings triggered an immediate merge request; lower-severity changes were batched. Every change required human review.
Outcome
Won first place in a 2025 internal innovation competition. The workflow ran end to end using mocked findings and a test repository. It did not reach production, and operational savings were not measured.
Read the case study
Project note

Legacy platform modernization

Served as the primary implementer and technical lead for a deployment API modernization, coordinating user validation and making release and rollback decisions.

Result

Modernized approximately 12 endpoints and 17 stored procedures. The legacy implementation was retired, and an endpoint that previously timed out above 50 items responded in under a second.

Read the project note
Project note

Multichannel notification service

Early in my engineering career, I built most of a shared notification service, including its Slack and email delivery components, and took responsibility for release and support. The service provided one authenticated internal API across four notification channels.

Result

Reached production and was used by a couple of teams before ownership transferred during a reorganization. I prepared the handoff documentation.

Read the project note

Building in the open

Projects I build on my own time, in public, with their design decisions, tests, and results documented alongside the code.

MITv0.1

repo-steward

Takes one bounded Go dependency upgrade on a local checkout, validates it in a container sandbox, repairs breakage only within declared scope limits, and prepares a pull request that a person approves before anything is pushed. Built on agent-runtime.

Result

On September 22 a real run upgraded a dependency on a private repository, paused for approval, and on resume opened a pull request that changed only go.mod and go.sum.

Read the write-up

MITv0.1

agent-runtime

A small Go runtime for tool-using agents where the controls sit outside the model: every tool call is schema-validated and policy-checked before it executes, limits on steps, calls, tokens, cost, and time are enforced by the runtime, and runs, steps, and events are persisted so a run can be interrupted, inspected, and resumed.

Result

Released at v0.1, with repo-steward as its first consumer. Model calls record and replay byte for byte, so the whole loop is tested without a network.

Read the write-up

Now

Next role

I want to build on my engineering experience in roles with broader responsibility for business outcomes, cross-team delivery, and operations. I’m particularly interested in understanding problems directly with the people experiencing them, deciding what’s worth doing, and helping a team carry it through. Over time, I want to take on responsibility for leading teams and running a business.

Building

Two public Go projects, MIT licensed. agent-runtime keeps the controls outside the model: tool calls are schema-validated and policy-checked, limits are enforced by the runtime, and every run, step, and event is persisted. repo-steward builds on it to take one bounded dependency upgrade, validate it in a sandbox, and prepare a pull request that a person approves before anything is pushed. Its first real run opened a pull request that changed only go.mod and go.sum.

Education

I hold a B.S. in Computer Science and am completing an MBA in IT Management, expected February 2027.

Experience

USAA

Software Engineer

December 2022 – May 2026

Built internal platforms, workflow automation, shared services, and developer tooling. Responsibilities included technical design, delivery coordination, production support, and guiding two intern cohorts.

Centuri Group

Application Developer I · Contract

February – August 2022

Contributed implementation and debugging across six internal applications using TypeScript, Vue.js, C#, and .NET. Supported testing, deployment, and post-launch work for three enterprise go-lives.

View résumé

Have a role or a problem where this experience could help?

I’d be glad to talk.

joey@joeylking.comLinkedInGitHubRésumé (PDF)