A tech lead writes in a post-mortem: "The bus factor on this service is 1 — only one engineer understands the deployment process." What does a bus factor of 1 indicate?
Bus factor (also "truck factor" or "lottery number") is the minimum number of team members who could become unavailable — hit by a bus — before a project comes to a complete halt. A bus factor of 1 is a critical risk: if that one person leaves, gets sick, or is otherwise unavailable, the team is stuck. A high bus factor (e.g., 5) means knowledge is well distributed. Improving bus factor: pair programming, documentation sprints, code reviews, and mentoring. Some teams use "lottery factor" as a more optimistic version — what if someone wins the lottery and quits tomorrow? Either way, it's a genuine engineering risk metric.
2 / 5
In a job listing, a startup writes: "We're a small team — you'll need to wear many hats: backend development, DevOps, and occasionally jumping into customer support." What does wearing many hats mean?
Wearing many hats comes from the idea of literally putting on different hats to assume different roles — a cowboy hat for one job, a hard hat for another. In a startup or small team context, it means one person is expected to perform multiple distinct roles. It can be attractive (you learn a lot) or exhausting (you're spread thin). When reading job descriptions: "wear many hats" almost always means "we're understaffed — you'll do more than one person's job." Related terms: "generalist" (vs. specialist), "full-stack" (technical version — handles both front and back), "T-shaped" (deep in one area, broad across others).
3 / 5
After a team restructuring, the engineering manager says: "We're trying to break down the knowledge silos — the frontend team had no idea how the API worked, and the backend team never spoke to design." What are knowledge silos?
Knowledge silos borrow from agricultural silos — tall grain storage containers that stand separately and don't mix. In organizations, silos are departments or individuals that hold expertise without sharing it with the rest of the team. This is a serious organizational risk: decisions are made without the full picture, on-boarding is slow (because one person holds all the context), and the bus factor stays low. Breaking down silos means: shared documentation, cross-functional teams, regular demos, and architectural decision records (ADRs) that everyone can read. "Silo mentality" (a related phrase) refers to a team or person who actively resists sharing information with others.
4 / 5
A developer asks in a Slack channel: "What does it actually mean when job posts say they're looking for a 10x developer?" What is typically meant by a 10x developer?
10x developer (or "10x engineer") is a claim that a single exceptional engineer can produce 10 times the output of an average engineer. The origin is a disputed interpretation of research studies from the 1960s–80s comparing programmer productivity. In practice, the term is highly controversial: critics argue it's used to justify hero culture, overwork, and poor team dynamics. Supporters say genuinely exceptional engineers can indeed multiply the productivity of a team — but through mentoring, system design, and unblocking others, not through raw code output. If a job posting emphasizes "10x talent", it may signal they value individual stars over team culture. Red flag or green flag depending on your values.
5 / 5
In a performance review, a manager describes an employee: "She's a T-shaped engineer — deep expertise in distributed systems, but comfortable across the full stack and able to contribute to frontend work when needed." What is a T-shaped engineer?
T-shaped is a career and skills metaphor: the vertical stroke of the "T" represents deep expertise in one domain (e.g., distributed systems, machine learning, frontend performance); the horizontal stroke represents shallower but functional knowledge across many areas (DevOps, frontend, testing, product, etc.). It's widely regarded as the ideal engineering profile for cross-functional teams — you can go deep when needed but can also contribute meaningfully across the project. Contrast with: "I-shaped" (deep in one area, unable to help elsewhere — risky for team flexibility) and "π-shaped" (deep in two domains — highly valuable). "T-shaped" is used in hiring, career conversations, and team-building discussions.