Technology Operation

Competition begins at 3:30. At 3:24 somebody asks whether anyone updated Station 6. Silence. Then: did we test the microphones? More silence. Then: who has the tournament login? Nothing is technically broken yet — but the operation is already in trouble.

Working is not the same as ready

A workstation that powers on, displays correctly, and takes mouse input still might have the wrong game version, disabled voice input, an unready account, an untested network connection, full storage, or missing required software. The computer works. The operation isn't ready. That distinction is the whole week.

Operations are about repeatability

One lab where someone walks around asking "did we do the thing?" from memory gets a different result every day, depending on who's asking and what they remember. A lab that runs the same short readiness procedure — power, login, network, game, audio, peripherals, final test — still hits problems sometimes, but the process stays visible, repeatable, and documented. That's operations.

Repeatable doesn't mean robotic. A checklist exists because humans forget things, especially under time pressure, with interruptions, when several people share responsibility, when a task happens infrequently, and when the system has a lot of dependencies — an esports lab checks all five boxes easily.

Operations happen at different times

Before use: is the environment ready? During use: what should be monitored? After use: what should be saved, closed, reported, or reset? When something changes — a software update, a new device, a new account, a new tournament requirement — the procedure has to change too.

Check versus verify

"Check internet" is weak — how, and what counts as checked? "Open the required online service and confirm connection" gives you something observable. Use check to mean looking at something, and verify to mean confirming a required function actually works.

A good checklist step answers

What, who, how, what counts as success, and what happens if it fails. That last one is easy to skip — but "fail, use spare headset" is what lets the team keep moving instead of stalling.

Lesson 1: Reliable Operations Are Repeatable

Compare memory-based, checklist-based, and verified operations, then design a dependency-ordered readiness sequence.

Lesson 2: Reading and Improving a Checklist

Audit deliberately weak checklists for vague steps, missing order, missing ownership, missing verification, and missing failure responses, then rewrite them.

Lesson 3: Operations Checklist Build

Build a Competition-Ready Operations Checklist for a fictional lab, then blind-test it on another group and revise it against real evidence.

Week 17 artifact

Your final artifact is a Competition-Ready Operations Checklist covering hardware, software, network, audio/communication, account/access, a whole-system readiness test, and failure responses — distinguishing check from verify throughout.

Learning targets

By the end of Week 17, you should be able to:

• explain why repeatable procedures improve operational reliability
• distinguish a working device from a competition-ready system
• explain why checklists reduce dependence on memory
• identify vague or unverifiable checklist steps
• write steps with clear completion criteria
• assign ownership for operational tasks
• include failure-response paths in a procedure
• identify when a checklist contains unnecessary complexity
• revise an operations procedure using testing evidence
• create a repeatable readiness process for an esports environment

One idea to keep: good operations should make "did we forget anything?" a boring question, because the answer is already visible.