EOEngineering OS
TEAM LEARNING SYSTEM · v1.0

Build engineers who
understand the system.

A practical operating system for growing cloud and DevOps capability—grounded in foundations, accelerated by AI, and proven through real work.

Explore the system →How the system works
CORE PRINCIPLE

Foundations are learned. Tools are learned just in time. AI accelerates execution. Projects create experience. Incidents create understanding. Reviews create judgment. Specialization creates expertise.

01 / THE OPERATING MODEL

One shared foundation. Many paths to expertise.

Progress upward—not by completing courses, but by demonstrating deeper judgment in increasingly realistic situations.

01

Foundations

The non-negotiable mental models every engineer carries.

02

Systems Thinking

See flows, boundaries, dependencies and failure modes.

03

Tooling

Learn products just in time, in service of a real problem.

04

Real Projects

Build, break, debug and defend client-like systems.

05

Specialization

Develop billable depth and become the team’s trusted expert.

Learn foundations deeply → understand the whole system broadly → learn tools just in time → specialize through real work.
02 / NON-NEGOTIABLE FOUNDATIONS

The knowledge that stays when tools change.

Do not teach this as a long prerequisite. Revisit it in a spiral: encounter → learn → implement → observe → break → debug → explain.

01

Linux & OS

Files, permissions, users, processes, services, systemd, CPU, memory, disk, packages, environment variables, logs and SSH.

An application is a process, running as a user, listening on a port, consuming resources and producing logs.
Open foundation →
02

Networking

IP, CIDR, subnets, routes, gateways, NAT, DNS, TCP/UDP, ports, HTTP/S, TLS, firewalls, proxies and load balancers.

Trace a request from a domain name, through every boundary, to the application and database.
Open foundation →
03

Application

Frontend, backend, API, request/response, REST, JSON, authn/authz, tokens, dependencies, app servers and DB connections.

Follow data from browser → API → database → API → browser.
Open foundation →
04

Git & Delivery

Repository, commit, branch, merge, pull request, conflicts, remotes, ignore rules, build, artifact, deploy and rollback.

Source → Build → Test → Artifact → Deploy → Run → Observe → Improve.
Open foundation →
05

Security

Least privilege, secrets, encryption, TLS, public/private exposure, IAM, trust boundaries, patching, audit and rotation.

Security is a property of every layer—not an advanced module added later.
Open foundation →
06

Data & Reliability

SQL, schema, connections, object/block/file storage, backups, restore, replication, HA, RPO/RTO, logs, metrics and traces.

State must be protected, observable and recoverable.
Open foundation →
PROJECT→Encounter concept→Learn foundation→Implement→Break & debug→Explain→DEEPER PROJECT
03 / KNOWLEDGE DEPTH

Replace “knows it” with a shared language.

A level is demonstrated capability—not course completion, confidence or time served. Depth varies by role and project need.

L0

Unknown

Never encountered it.

L1

Aware

Know what it is and the problem it solves.

L2

Understand

Explain how it works and where it fits.

L3

Practitioner

Implement with docs/AI and solve normal problems.

L4

Independent

Design, make trade-offs and debug difficult issues.

L5

SME

Advise clients, set standards, review and mentor.

EXAMPLE SKILL MATRIX

Set target depth by role.

Everyone shares a base; nobody must become an SME in everything.

CapabilityJuniorEngineerSenior / SME
LinuxL3L4L4
NetworkingL3L4L4–5
AWSL3L4L5
SecurityL2–3L4L5
TerraformL3L4L5
KubernetesL1–2L3L4–5
ObservabilityL2–3L4L5
04 / THE REUSABLE PROJECT LADDER

One application. Sixteen levels of engineering judgment.

Keep evolving the same FastAPI system so each new idea lands on a familiar mental model. Every level includes a build, an incident and a design conversation.

01

Local application

Browser → FastAPI → SQLite → MySQL

Application flow · APIs · SQLOpen project →
TASK 1
02

Authentication + Git

bcrypt, JWT, protected APIs, env secrets, GitHub

Identity · source controlOpen project →
TASK 2
03

EC2 + systemd

Ubuntu, SSH, Uvicorn, services and logs

Linux · processes · operationsOpen project →
TASK 3
04

Nginx + HTTPS

Reverse proxy, DNS, ports 443/8000, TLS

Networking · web servingOpen project →
TASK 4
05

Amazon RDS

Replace self-managed MySQL with managed MySQL

Managed data · connectivityOpen project →
TASK 5
06

Private AWS architecture

3-tier VPC, private EC2/RDS, IAM role and private S3 uploads

Boundaries · identity · storageOpen project →
TASK 6
07

Terraform

Rebuild understood infrastructure as code

State · dependencies · repeatabilityOpen project →
08

CI/CD

Build, test, scan, artifact, deploy, verify and rollback

Delivery automationOpen project →
09

Observability

Central logs, metrics, dashboards and alerts

Evidence · detectionOpen project →
10

High availability

ALB, Auto Scaling, health checks and Multi-AZ

Scaling · failure domainsOpen project →
11

Security hardening

Secrets, patching, scanning, audit and least privilege

Defense in depthOpen project →
12

Containers

Package the app, config, networking and registry

Portability · immutabilityOpen project →
13

Amazon ECS

Managed orchestration and service deployment

Scheduling · managed platformOpen project →
14

Kubernetes

Pods, services, ingress, config, health and scaling

Orchestration mental modelOpen project →
15

Cost optimization

Measure, right-size, schedule and redesign

Unit economics · FinOpsOpen project →
16

Disaster recovery

Backups, restore drills, RTO/RPO and runbooks

Recoverability · resilienceOpen project →
TASKS 1–4 · PROVEN FOUNDATION

The team already moved the app from local browser/FastAPI/database flow to JWT + Git, then EC2/Uvicorn/systemd, and finally Nginx, DNS and HTTPS—learning ports, processes, services and request flow in context.

TASKS 5–6 · CLOUD TRANSITION

Next, MySQL moves to Amazon RDS. The application then becomes a 3-tier AWS system with private EC2, private RDS, IAM roles, private S3 file storage, authenticated user uploads, Nginx and Terraform.

05 / THE TASK PLAYBOOK

Every assignment follows the same learning loop.

AI is allowed during the build. Ownership is proven through explanation, verification, failure testing and reflection.

01Problem→
02Concepts→
03Build→
04Explain→
05Verify→
06Break→
07Reflect
50%

BUILD

Implement a working solution. Develop execution and integration ability.

30%

INCIDENT

Diagnose something already broken. Develop evidence-led troubleshooting.

20%

DESIGN

Start without implementation. Develop architecture and trade-off judgment.

Suggested junior mix. Shift senior engineers toward approximately 30% Build · 30% Incident · 40% Design/Review.

06 / DEFINITION OF DONE

“The application works” is the beginning—not the finish.

A task closes only when the engineer can prove, explain and operate what they submitted.

AI
07 / AI-FIRST, NOT AI-BLIND

Use AI aggressively.
Own every output.

AI is encouraged for

Learning concepts · boilerplate · Terraform · scripts · CI/CD YAML · debugging · error explanation · research · documentation · comparisons · code review · architecture brainstorming

THE ONE RULE

If you submit it,
you own it.

You must answer

  • What does it do?
  • Why is it needed?
  • What are the risks?
  • How do you know it works?
  • How would you troubleshoot it?

AI usage is not cheating. Unverified AI output is bad engineering. Never paste client secrets, credentials or restricted data into an unapproved tool.

08 / ARCHITECTURE REVIEW

Draw it. Defend it. Improve it.

A short whiteboard review builds judgment faster than a polished presentation. The mentor attacks assumptions constructively; the engineer follows the evidence.

1Why this component?
2What happens if it fails?
3What is publicly exposed?
4Who has access—and why?
5How do we observe it?
6How does it scale 10×?
7How do we recover?
8What does it cost?

Reusable review rubric

Score each 1–4 · Evidence required
Understanding

Can explain purpose, flow, dependencies and state without hiding behind tool syntax.

1  2  3  4
Implementation

Solution is repeatable, readable, correctly configured and appropriate to the requirement.

1  2  3  4
Verification

Uses evidence—tests, logs, metrics and direct checks—to prove behavior.

1  2  3  4
Troubleshooting

Moves from symptom → hypothesis → evidence → test → root cause → fix → verify.

1  2  3  4
Security

Identifies exposure, identity, secrets, data protection and least-privilege concerns.

1  2  3  4
Reliability

Explains failure modes, backups, recovery, scaling and operational ownership.

1  2  3  4
Trade-offs

Can defend choices across complexity, cost, speed, risk and maintainability.

1  2  3  4
Communication

Draws clearly, documents decisions and teaches the next engineer.

1  2  3  4
09 / SPECIALIZATION PATHS

T-shaped engineers. A stronger team.

Broad DevOps fluency enables collaboration. Primary and secondary specializations create client-ready depth and distributed ownership.

10 / TEAM OPERATING RHYTHM

Turn every client need into reusable team capability.

01

Discover

Translate project needs into capability gaps.

02

Baseline

Update the skill matrix with evidence.

03

Assign

Choose task type, target level and reviewer.

04

Learn JIT

Focused 2–3 day sprint on the immediate problem.

05

Deliver

Pair with an experienced engineer; build real work.

06

Review

Verify evidence, run incident and design review.

07

Capture

Save ADR, runbook, checklist and lesson learned.

08

Teach

Engineer demos, mentors and improves the standard.

THE COMPOUNDING LOOP

Project knowledge must leave the individual.

Problem solved → decision recorded → runbook created → demo delivered → next engineer practices it → standard improves.

11 / ONBOARDING JOURNEY

A guided first 90 days.

Use readiness gates, not rigid dates. Move faster when evidence is strong; add deliberate practice where mental models are weak.

Foundation & first shipment

Baseline L0–L5 · team map · Tasks 1–3 · local app, auth/Git, EC2/systemd · first incident · architecture explanation · AI policy sign-off.

Gate: ship a service and trace its request, process, port, config and logs.
12 / REUSABLE TEMPLATES

The minimum useful team kit.

□

TASK BRIEF

Problem · context · constraints · acceptance criteria · target concepts · target L-level · evidence required

□

DESIGN RECORD

Context · options · decision · trade-offs · security · reliability · cost · consequences

□

INCIDENT REPORT

Impact · timeline · evidence · root cause · contributing factors · fix · prevention · owner

□

LEARNING LOG

What I expected · what happened · what I learned · evidence · remaining gaps · next action

□

RUNBOOK

Purpose · prerequisites · safe steps · verification · rollback · escalation · owner · last tested

□

TEACH-BACK

Mental model · live flow · one failure · key trade-off · audience questions · reusable artifact