Technical Leadership: Phrases for Tech Leads & Staff Engineers
5 exercises on engineering direction, team empowerment, and risk documentation phrases. Choose the most natural and professional option.
0 / 5 completed
1 / 5
You're a tech lead setting the direction for a new system. How do you communicate the engineering strategy?
KEY PHRASE: "The engineering direction here is to..." This is authoritative leadership phrasing — it signals a deliberate architectural decision, not an opinion. Pairing it with a rationale ("to build X so that Y") demonstrates the thinking behind the choice and helps the team internalise the principle, not just follow an order. Real examples: "The engineering direction here is event-driven — all state changes go through the event bus"; "Our direction is API-first — no tight coupling to the UI layer"; "The engineering direction is async-first — synchronous calls only where latency is irrelevant." Options A and C are personal opinions, not direction. Option D is vague and gives the team nothing to act on.
2 / 5
A junior engineer asks which approach to take. You want to empower them to decide but offer guidance. What do you say?
KEY PHRASE: "I want to empower you to make the call — but my recommendation is..., because..." This is the hallmark of servant leadership. It delegates ownership explicitly ("empower you"), makes your experience available ("my recommendation"), and models good decision-making by explaining the reasoning ("easier to reverse"). This combination gives the junior engineer both autonomy and a framework. Real examples: "I'll empower you on this — my lean is toward the simpler approach, but either works technically"; "Empower you to decide — I'd go with B for the reversibility argument, here's why." Options A and C abdicate — they delegate without guidance. Option B gives an answer without the coaching framing that makes it a growth moment.
3 / 5
You want the team to agree on the technical approach before anyone writes code. How do you lead this?
KEY PHRASE: "Let's align on the approach before we start — I'd like everyone to read the design doc and share concerns by Thursday" This is collaborative leadership: "align" is the professional coordination term, "before we start" frames it as proactive, and adding a concrete action (read the doc, share concerns) with a deadline (Thursday) makes it actionable rather than a vague directive. Real examples: "Let's align on the data model first — I'll post the options in the doc by EOD"; "Align before we start — I don't want us diverging mid-sprint on something this foundational." Option B sounds like a demand for conformity. Option C is negative without proposing a process. Option D sounds like a warning, not an invitation to collaborate.
4 / 5
You're worried the current approach will be hard to understand and maintain in 18 months. How do you raise it?
KEY PHRASE: "I'm concerned about the long-term maintainability — specifically, the implicit coupling between..." This is how senior engineers raise design concerns without blocking progress. "I'm concerned about" is softer than "this is wrong" — it invites discussion. "Specifically" shows you've diagnosed the root cause (implicit coupling), not just felt uneasy. This moves the conversation toward a solution. Real examples: "Concerned about long-term maintainability — the config is scattered across 12 files with no central schema"; "Long-term maintainability is my worry — no one will remember why this was done in 18 months without a comment or ADR." Options A and D are alarmist ("going to be hard", "we'll regret"). Option B is too vague to drive a design conversation.
5 / 5
You want to formally capture a technical risk before moving forward. How do you phrase this?
KEY PHRASE: "This is a technical risk we should document in the ADR so future engineers understand the trade-off we accepted" This is the most professional and specific form. ADR (Architecture Decision Record) is the standard mechanism for capturing decisions, their context, the alternatives considered, and the risks accepted. Framing it as "a trade-off we accepted" is important — it signals deliberateness, not negligence. Real examples: "Document this risk in the ADR — it's a conscious trade-off, not an oversight"; "Add a risk section to the ADR covering the eventual consistency gap"; "This decision belongs in an ADR with the risk clearly stated so the next team isn't blindsided." Options A and B are too vague. Option C ("risk register") is a project management term, not an engineering-specific artefact — ADRs are the right venue for technical decisions.