Free · share it freely
The Engineering Translation Guide
The whole problem is that you and your engineers use the same words to mean different things. Here are the ones that trip up non-technical managers most — in plain English. Each names the chapter of No Code Required that goes deeper.
No sign-up. Forward it to whoever needs it.
People & teams
- T-shaped engineerCh 2 · Composition
- Someone with broad general knowledge (the top of the T) and deep expertise in one area (the stem).
- Pair programmingCh 11 · Motivating
- Two engineers working on the same code at the same time — usually one typing while the other reviews and thinks ahead.
- Psychological safetyCh 5 · Trust & Respect
- The shared belief that a team is safe for disagreement, mistakes, and questions without fear of punishment. Google's Project Aristotle found it the #1 factor in team effectiveness.
- Zone of Proximal DevelopmentCh 11 · Motivating
- The gap between what someone can do alone and what they can do with help — the skills a person is close to mastering, within reach with the right guidance.
Planning & process
- MVP — Minimum Viable ProductCh 3 · Process
- The smallest thing you can build that answers your most important question, then iterate. It's a learning tool — not a tiny version of the finished product.
- Agile · Scrum · Kanban · WaterfallCh 3 · Process
- Ways of organizing the work. Waterfall plans everything up front (good when requirements are stable); Kanban flows work continuously (good for support); Agile is the umbrella for short, repeating cycles, with Scrum its most common flavor. Adaptive methods need more management, not less.
- EpicCh 6 · Directing
- A large body of work broken into smaller tasks (sometimes called stories). "Build the admin panel" is an epic; "Add the user search field" is a task.
- User storyCh 6 · Directing
- A way to describe work by outcome: "As a [type of user], I want [something] so that [reason]." You write the goal; the engineers handle the how.
- Code reviewCh 3 · Process
- Engineers reading each other's code before it ships, to catch bugs and share knowledge.
- Black-box problemCh 2 · Composition
- A problem you can only diagnose from the outside — like a car with no dashboard lights, you try things and see what changes. A white-box problem lets you see the internals directly.
Quality & operations
- Technical debtCh 4 · Output
- Accumulated shortcuts that compound like interest until you pay them down. Engineers spend roughly a third of their time fighting it; the question is whether that time is planned and visible — or not.
- API — Application Programming InterfaceCh 9 · Decisions
- A way for one piece of software to talk to another. A "third-party API" is someone else's service that your software connects to.
- Feature flagCh 12 · Force Multipliers
- A switch in the code that turns a feature on or off without deploying new code — like a light switch you can flip remotely.
- ObservabilityCh 12 · Force Multipliers
- The ability to understand what a system is doing by examining its outputs: logs, metrics, and traces.
- MTTR — mean time to recoveryCh 12 · Force Multipliers
- The average time from when a problem is detected to when it's resolved. Lower is better.
Every term here is one idea from the book — explained in plain English, in context.
Found this useful? See where you stand leading engineers →