Domain 4 — Technical Judgment
Technical Judgment is the ability to exercise sound engineering judgment without doing the engineering yourself. It is the domain most misunderstood by new managers, who fear that stepping back from the code makes them irrelevant. The truth is the opposite: credibility comes not from writing the most code but from reasoning well about technical reality and applying that reasoning to leadership decisions. This domain carries 20% of the EMA-I exam (12 questions).
The throughline is judgment over throughput: knowing enough to ask the right questions, distinguishing real risk from hypothetical, deciding when "good enough" is good enough, and — hardest of all — knowing when to step in and when to stay out. The exam rewards options that show restraint and systems thinking over those that show a manager trying to out-engineer their team.
4.1 Evaluating architectural decisions and their organisational consequences
Managers rarely design systems, but they must be in the room when systems are designed — because architecture has organisational consequences that outlast any release. Conway's Law captures the core insight: systems tend to mirror the communication structures of the organisations that build them. Architecture and team design are two views of the same decision; a manager who ignores this ships org problems into the codebase (and vice versa).
The competency is evaluating decisions for their trade-offs and their reversibility, not redesigning them. Good architectural judgment weighs consequences a manager is uniquely positioned to see: how a choice affects team boundaries and coordination cost, how it constrains hiring, how hard it will be to change later. The most important filter is reversibility — invest deliberation in one-way-door choices (data models, public contracts, core technology bets) and let the team move fast on the reversible ones.
A manager's value here is the quality of the questions: "what does this assume?", "what happens when this fails?", "how would we undo this?", "who has to coordinate because of this?" — not the answers.
Strong judgment looks like: being present for major design decisions and improving them through questions; weighing organisational and long-term consequences, not just technical elegance; spending scrutiny on irreversible choices; respecting Conway's Law in how teams and systems are shaped.
Common pitfalls: rubber-stamping architecture you don't engage with; over-indexing on technical elegance while ignoring coordination cost; treating all decisions as equally weighty; ignoring how team structure and system structure shape each other.
Self-check: What does Conway's Law imply for a manager reorganising teams? Why focus architectural scrutiny on reversibility?
4.2 Technical debt — recognising, quantifying, and scheduling repayment
Technical debt is the implied cost of future rework created by choosing an expedient solution now. Like financial debt, a controlled amount can be a sensible trade (ship now, fix later); left unmanaged, the interest — slower delivery, more bugs, more toil — compounds until the team can barely move.
The competency is treating debt as a managed, visible quantity rather than a vague complaint. That means recognising it (distinguishing deliberate, prudent debt from reckless mess), making it visible (tracked, with its impact named in terms of delivery and risk), and scheduling repayment continuously rather than waiting for a mythical "we'll fix it later" that never comes. The strongest investment cases tie debt paydown to business impact: "this module causes a third of our incidents and doubles the time to add features here."
Two anti-patterns bracket the failure modes: never paying debt down (velocity slowly collapses) and demanding a total rewrite (usually a high-risk way to re-learn the same lessons). The sustainable path is incremental repayment, often alongside feature work in the areas you're already touching.
Strong judgment looks like: distinguishing prudent from reckless debt; making debt and its cost visible; paying it down incrementally and continuously; justifying paydown in delivery and risk terms.
Common pitfalls: letting debt accumulate invisibly until velocity collapses; arguing for paydown on purely aesthetic grounds; betting on a big-bang rewrite; treating all debt as equally urgent.
Self-check: Why is the financial-debt analogy useful — and where does deliberate debt differ from reckless debt? Why is continuous incremental repayment usually safer than a rewrite?
4.3 Code review culture and quality standards
Code review is one of the highest-leverage quality and culture mechanisms a team has — and the manager sets its tone. Done well, review catches defects, spreads knowledge, and raises the shared standard; done badly, it becomes a bottleneck, a battleground, or a rubber stamp.
The competency is shaping review as a healthy, shared standard rather than gatekeeping. Healthy review is timely (slow review blocks the whole team and is a major contributor to long lead times), kind and specific (critique the code, not the author), and proportionate (don't bikeshed trivia while waving through risky logic). Automating the objective parts — formatting, linting, tests in CI — frees human review for what only humans can judge: design, clarity, and intent. Standards should be explicit and shared (style guides, definitions of done) so "good" isn't a matter of whichever reviewer you drew.
Quality is broader than review: it's the whole system of tests, CI, and guardrails that makes doing the right thing the easy thing. A manager's job is to invest in that system, not to personally inspect every change.
Strong judgment looks like: keeping reviews fast and respectful; automating objective checks so humans focus on design and intent; making standards explicit and shared; treating review as knowledge-sharing, not gatekeeping.
Common pitfalls: letting reviews sit for days and block delivery; reviews that attack the author or bikeshed trivia; "LGTM" rubber-stamps that catch nothing; relying on heroics instead of CI and guardrails.
Self-check: Why is slow code review a delivery problem, not just a quality one? What should be automated so human review can focus on what matters?
4.4 Staying technically credible while leading through others
When you stop coding daily, breadth fades slowly and depth fades fast — but systems understanding, the knowledge that actually matters for leadership, persists if you maintain it. The competency is keeping enough technical currency to lead well without becoming the bottleneck you're trying to avoid.
Credibility for a manager is not being the strongest coder; it's understanding the system well enough to ask sharp questions, telling real risk from hypothetical, and knowing whom to trust on what. Practices that sustain it without creating a bottleneck: reading code and design docs to stay close to how the system evolves (without becoming a required approver), staying in the room for hard decisions, and going deliberately deep in one area each quarter rather than shallow everywhere. The most credible managers are comfortable being the least knowledgeable person about a given technology and saying so — "you know this better than I do; walk me through the trade-off" builds more trust than pretending.
Trying to remain the top individual contributor while managing usually fails both jobs: the team is bottlenecked on you and your management is neglected.
Strong judgment looks like: maintaining systems understanding deliberately; reading code/designs to stay current without gatekeeping; trusting and deferring to engineers' depth; being honest about the limits of your knowledge.
Common pitfalls: clinging to being the best coder and becoming the bottleneck; faking technical understanding you don't have; drifting so far from the system you can't reason about it; equating credibility with code volume.
Self-check: Which kind of technical knowledge matters most for a manager, and why does it persist while others fade? Why does "you know this better than I do" build credibility rather than undermine it?
4.5 Knowing when to intervene — and when not to
The hardest technical judgment a manager exercises is restraint. You will often see a team heading toward a decision you'd make differently. The instinct to step in is strong; acting on it too readily robs the team of ownership and learning, and signals you don't trust them.
The competency is a deliberate intervention threshold. Intervene when the cost of being wrong is high and hard to reverse (a one-way door, a safety/security/data-integrity risk, a customer-impacting mistake in flight). Stay out when the decision is reversible and the team will learn more by owning the outcome than by following your call — even if their path isn't the one you'd choose. When you do intervene, do it by raising the considerations the team may have missed, not by overriding by authority; preserve their ownership wherever you can.
This restraint is what grows engineers into senior decision-makers. A manager who makes every call produces a team that can't make any.
Strong judgment looks like: intervening on high-cost, irreversible risks; letting reversible decisions ride so the team learns; influencing through questions rather than overriding by authority; preserving ownership.
Common pitfalls: overriding decisions because they differ from your preference; staying out of a genuinely dangerous, irreversible call to avoid conflict; "intervening" by dictating rather than surfacing considerations; teaching the team that you'll always make the final call.
Self-check: What two factors most justify stepping in? Why can constant intervention weaken a team even when each individual call is "correct"?
Key takeaways
- Engage architecture for trade-offs, reversibility, and organisational consequences (Conway's Law) — through questions, not redesigns.
- Treat technical debt as a visible, managed quantity; repay it incrementally and justify paydown in business terms.
- Make code review fast, kind, and standard-driven; automate the objective checks.
- Sustain systems understanding to stay credible; lead through others rather than out-coding them.
- Intervene only on high-cost, irreversible risks; let reversible decisions teach the team.