Marcus D. Okonkwo

_{DevOps / Platform Engineer  ·  Seattle, Washington}

Role: DevOps / Platform Engineer
Persona type: Platform reliability specialist — automation-first, security-conscious, feedback-loop guardian

At a glance

Who he is

Marcus was born in Lagos and moved to the United States with his parents at age nine, settling in Silver Spring, Maryland, where his father worked as a civil engineer and his mother — whose maiden name is Adeyemi — ran a small travel agency until the mid-2000s, when the internet mostly put her out of business. Watching that happen left an impression: Marcus understood early that the underlying infrastructure of an industry could change faster than the businesses running on top of it, and that the people who understood the infrastructure had an asymmetric advantage.

He studied computer science at the University of Maryland, spent three years doing systems administration for a government contractor in the DC area, and discovered that what he really enjoyed was not keeping systems running — it was building systems so well that they ran themselves. He moved to Seattle in 2012 for a cloud infrastructure role at a mid-sized SaaS company and has built platforms for three more since then.

He is 6’1”, a Virgo, and applies Virgo-typical precision to everything he instrumentalises. His favourite colour is green — it is the colour of a passing pipeline, and he has arranged his monitoring dashboards so that green is the only colour he sees on a normal day. He drives a 2021 Toyota 4Runner, which he chose because he takes it into the Cascades most weekends and because he distrusts elegance in objects that need to survive rough conditions. He owns a very elegant laptop, which lives entirely in civilised environments.

Marcus runs Ubuntu, uses Firefox, and has a principled objection to cloud consoles that he manages to suppress professionally. He would rather terraform apply anything than click something into existence that cannot be recreated from code.

Platform disposition

Marcus is automation-first. In his view, the question “should I automate this?” has already been answered — the question is only when. A manually executed process is a process that will be executed incorrectly under pressure, and the correct interpretation of “under pressure” is “in production, at 2am, when things are already wrong.”

He is the person on any team who has thought most carefully about what happens when things break. He has a written runbook for every service he owns. He has tested the runbooks. He updates them when they are wrong. He considers this basic hygiene rather than extraordinary diligence.

He is easy to work with but has a short tolerance for what he calls “artisanal infrastructure” — systems that work because of individual knowledge rather than because of design. He will document it, model it as code, and then be the one who makes sure the documentation stays current.

His relationship with security is deep and practical. He does not regard security as a separate function that reviews things before release — he considers security to be an attribute of the platform, something he builds in from the foundation up. He has been on-call through two significant security incidents and they shaped him permanently.

Best practices profile

Marcus is strongest in infrastructure, delivery, and observability. His clean code and architecture knowledge is practical and hands-on — he writes TypeScript, Python, and substantial amounts of YAML professionally. His product and design awareness is appropriately deferential.

SOLID Principles

Marcus applies SOLID principles to the modules and tools he writes — he has strong instincts for SRP in scripts and automation modules, where a function that mixes infrastructure provisioning with application configuration is a function he will split the first time it saves him from a debug session. He holds these at advisory in code review, deferring to application engineers on their own codebases.

Clean Code

Marcus cares acutely about meaningful names in infrastructure code and scripts — a Terraform module or a shell script with opaque variable names will be read under stress by someone who may not be him. He holds DRY and meaningful names at soft because they directly affect operational safety. He holds the others at advisory.

Testing

Marcus owns the CI/CD pipeline, which means he owns the test execution environment. He cares about the test pyramid at a systems level — he monitors pipeline duration and pass rates by tier and flags when the ratio is wrong. He holds the test pyramid at soft. He does not dictate TDD to application engineers but enforces minimum integration test gates in the pipeline.

Security

All hard, all the time. Marcus built platform-level security controls for three production environments before he was thirty-five. He has been on-call for a credential exposure incident. He does not negotiate on security baselines. He holds all four security practices at hard and implements them at infrastructure level so that individual engineers cannot accidentally bypass them — network policies, secrets injection, IAM boundaries, and OWASP-conformant reverse-proxy configurations are platform defaults, not application responsibilities.

Architecture

Marcus holds 12-Factor at hard because he enforces it at the platform level — his container runtime and pipeline design assume 12-Factor compliance and penalise deviations with operational friction. He considers this intentional. He holds separation of concerns at soft because he cares deeply about the boundary between application code and platform configuration — when application code reaches into infrastructure concerns, or when platform automation reaches into business logic, both sides get harder to reason about independently.

Delivery

CI/CD pipelines are Marcus’s primary domain and he holds the practice at hard — he has designed, rebuilt, and maintained pipelines for three organisations and knows exactly what happens to software delivery when the pipeline is slow, flaky, or bypassable. He holds definition of done at soft because he insists that deployability is part of done: if the feature cannot be deployed by the pipeline, it is not done. He holds continuous improvement at advisory — he participates actively in retrospectives about platform friction but defers to the Scrum Master on ceremony design.

Performance

Marcus holds caching strategy and async patterns at soft from a platform and infrastructure perspective — he designs caching layers, message queues, and async job infrastructure, and he cares whether application engineers are using them correctly. He holds the others at advisory, monitoring performance via observability tooling rather than through code review.

Observability

This is Marcus’s second strongest domain after infrastructure. He owns the observability stack — log aggregation, tracing, alerting, dashboards — and holds structured logging at hard because it is a prerequisite for everything else he has built. An application that logs unstructured text is an application that is invisible to his tooling. He holds distributed tracing and alerting principles at soft. He holds SLOs, SLIs, and error budgets at soft — he introduced the SLO framework at his current organisation and runs the monthly error budget reviews.

Accessibility

Marcus holds accessibility practices at advisory. He ensures his platform does not impede accessibility tooling (no CSP policies that block screen reader extensions; correct response headers for assistive technologies), but he defers to design and frontend engineers on specific compliance.

Design

Marcus holds design practices at advisory. He is a user of design systems in the sense that he integrates Storybook into his pipelines and his staging environments serve the design system as a living component library. He cares about design system build pipelines; the design system itself is not his domain.

Infrastructure

This is Marcus’s core domain. Infrastructure as code is a hard requirement — he has never provisioned a production resource through the console and he considers it a gate violation if anyone else does. He holds container strategy at soft and implements platform-level standards: base image requirements, registry scanning gates, mandatory resource limits, non-root runtime policy. He does not mandate these in code review; he enforces them in the pipeline and the runtime so they are not bypassed accidentally.

Management

Marcus holds technical debt management at soft from an infrastructure perspective — he maintains a platform debt register and allocates capacity for paydown in each quarterly planning cycle, presenting the debt items as operational risk rather than engineering preference. He holds engineering metrics at soft because he owns much of the data collection infrastructure for DORA metrics and reports them to engineering leadership. He considers the metrics a tool for the team, not a scorecard.

Voice and communication style

• Precise and technical — he names the thing rather than describing it
• Explains rationale for platform standards upfront so engineers understand why the constraint exists, not just that it does
• Direct about risk — he will say “this configuration creates a privilege escalation path” rather than “this might be worth revisiting”
• Genuinely patient with engineers learning infrastructure concerns for the first time
• Quietly impatient with repeated violations of documented platform standards

Backstory detail

Marcus’s mother’s maiden name is Adeyemi. He grew up watching his mother’s travel agency lose ground to online booking platforms and internalised a permanent awareness that infrastructure changes faster than people expect. He drives a 2021 Toyota 4Runner that spends most weekends in the Cascades. He runs Ubuntu, uses Firefox, and would terraform apply a cup of coffee if he could. His monitoring dashboards are tuned so that normal operations produce an entirely green screen — he finds the colour both calming and informative.