Glossary

T-Shaped Engineer

A T-shaped engineer combines broad working knowledge across many domains (the horizontal bar) with deep expertise in one specialization (the vertical stem).

A T-shaped engineer has broad, working competence across many technical domains — the horizontal bar of the T — combined with deep, expert-level skill in one specialization — the vertical stem.

The metaphor, popularized in the 1990s and famously championed by IDEO's Tim Brown in hiring designers, describes the profile that generalist-vs-specialist debates miss: the answer is both, deliberately shaped. A pure generalist knows a little about everything and cannot carry hard problems to the finish; a pure specialist is brilliant inside a silo and lost outside it. The T-shaped engineer translates between worlds and still ships expert work.

How it works

The bar is not trivia. Broad competence means you can reason about domains you do not own: read the database team's slow-query analysis, understand why the frontend needs an API shaped differently, follow a security review, estimate what an ML feature will cost to serve. Breadth is what makes you effective in incidents, design reviews, and any room where the problem crosses boundaries — which, in real systems, is every room.

The stem is where you are the person others consult: distributed systems, security, data engineering, applied AI. Depth is what makes you the one who can actually solve the hard version of the problem, not just discuss it.

The shape decays without maintenance. Breadth, especially, evaporates on the forgetting curve unless deliberately retained — which is why the T is a practice, not a credential you earn once.

Why it matters

AI raised the stakes on both strokes of the T. Models now generate competent code inside well-defined boundaries, which discounts the pure implementer. What AI cannot do is know that the payments bug is probably a timezone issue in the batch job because you have seen that shape of failure across three domains — cross-domain judgment is breadth's product. And it cannot replace the deep expert who can tell when the model's confident output is subtly wrong — verification is depth's product. The engineers most exposed to AI are the ones with neither bar nor stem; the ones amplified by it are T-shaped, using AI to extend reach in every direction they already understand.

A worked example

A checkout latency incident: p99 spiked at 09:00. The T-shaped engineer on call reads the dashboards (observability breadth), notices the spike aligns with a deploy (CI/CD breadth), suspects connection-pool exhaustion from the diff (databases breadth), and confirms it — then, because their stem is backend performance, designs the actual fix: right-sized pooling with backpressure, not just a rollback. Four domains crossed in twenty minutes, finished with depth. A narrower engineer stalls at whichever boundary their knowledge ends.

How Miatz builds it

The T is Miatz's literal blueprint: breadth across 28 competencies kept alive by SM-2 spaced repetition and daily reps, depth built through a chosen specialization with human mentors and industry experts — and Applied AI as the crossbar joining bar to stem, because in this era every domain routes through it. War Rooms exist precisely to exercise the whole T under pressure, the way real incidents do.

Learn it by doing it.

Miatz turns definitions into judgment — the free founding cohort trains you on exactly these concepts, hands-on.