Skip to content

The complete learning route

From understanding the work
to owning the delivery.

A forward-deployed engineer turns an organization's difficult workflow into a useful, dependable system—and equips other people to own it. This route connects business understanding, software engineering, AI, human judgment and service operations around one project.

6 connected stages12 capability areasShared core + cloud and industry specializations
Find your starting point Developer, architect or new to software

New to software or AI

Start with the vocabulary and engineering workbench. Build and test a small program before moving into agents. Use the 101 explanations whenever a concept is unfamiliar.

Open the first principles library →

Practising developer

Use a reviewed change to establish your coding baseline. Give equal attention to discovery, evaluation, human decisions and receiving ownership—the parts a coding tool cannot decide for you.

Begin with the client workflow →

Architect or technical lead

Bring your systems experience, then demonstrate an actual implementation and recovery. Treat diagrams as claims to verify, and connect platform choices to workload and operating responsibility.

Inspect the integration proof →

Stage 1 of 6

Understand the work

Learn the language of the job and establish the engineering foundations.

01

Business discovery & problem framing

Whose work are we improving, and what would useful look like?

Start with a recent real task, its vocabulary, exceptions and receiving owner. Compare automation with a simpler process or interface change before choosing an agent.

Builds onNo previous stage required

What you need to understand

  • Workflow observation and interviewing
  • Domain vocabulary and exception mapping
  • Constraints, scope and acceptance criteria
  • Stakeholder decisions and value hypotheses

Learn it in context

Forward-deployed engineering: client deliveryDiscover and scope the first useful slice
Human-centered AI delivery & adoptionSeparate observation from assumption

Course lessons use your existing training access. The practice workbook and curriculum map are free.

Evidence to bring to review

A current-state workflow, evidence-backed problem statement and a receiving owner with explicit acceptance criteria.

Then change one condition

An exception contradicts the sponsor's initial request. Explain how it changes the proposed scope.

Workflow and receiving-review workbook
02

Software engineering & the working environment

Can you build, inspect and repair a small system yourself?

Learn terminals, processes, Git, configuration, HTTP, testing and debugging. Use coding assistants while retaining responsibility for the code, permissions and review.

Builds onNo previous stage required

What you need to understand

  • CLI, Git, repository context and dependency management
  • Python/TypeScript application structure and typed data
  • HTTP, REST, SDKs, streaming and configuration
  • Tests, debugging, code review and secure permissions

Evidence to bring to review

A small runnable change, a meaningful failing-then-passing check and a reviewable diff you can explain without the assistant.

Then change one condition

A dependency or configuration value is missing. Diagnose the failure before asking an agent to edit code.

First principles and technical vocabulary

Depth without losing the thread

Choose a specialization.
Keep the engineering core.

Build depth in one cloud, compare the boundaries in the others, and choose an industry context. Certification study complements the practical work; vendor exams and field acceptance are separate assessments.

Why this curriculum is structured this way Research reviewed 2026-10-23

The route combines published FDE practice with cloud architecture, software delivery, reliability, AI risk, accessibility and economic reasoning. The lessons and exercises are original LockedIn Labs material. These references inform the curriculum; they do not imply vendor endorsement or accreditation.

Completion of reading or a synthetic lab does not establish field competence. The final review needs observed work, domain judgment and a receiving owner in the demonstrated environment.