Back
Keentune
Engineering Leadership curriculum 21 chapters
·
132 concepts
·
free
Everything the adaptive question bank can teach and test in Engineering Leadership, from foundations through advanced practice. Work through it in order, or start practising and let the questions find your level.
Start practising Engineering Leadership
New here? Read the Engineering Leadership guide
A free 17-minute primer — the mental model, the mistakes beginners make, and what to practise first.
A. Stepping into leadership
•
a lead is measured by what the team ships, never by their own commit count
•
one meeting costs a maker the half-day around it, not the hour inside it
•
name the changed relationship once, explicitly, rather than hoping it settles itself
•
taking the critical-path task yourself makes you the bottleneck and starves the team of growth
•
DORA measures vision, intellectual stimulation, inspirational communication, supportive leadership, personal recognition
•
good leadership lifts delivery only by enabling technical and process capabilities, not on its own
B. Delegation and decision rights
•
hand over the definition of done and the constraints; prescribing the path is supervision
•
the same task can be delegated as "do it and report", "recommend and I decide", or "decide and act"
•
how directive to be depends on experience with *this* task, not on overall seniority
•
the test of a delegation is who owns the next step when the conversation ends
•
work done 80% as well as you would have done it is a success, not a defect to correct
•
one-way doors deserve a heavyweight process; two-way doors should be decided fast and locally
C. 1:1s, coaching and motivation
•
the report sets the agenda; the lead's questions fill the gaps
•
a 1:1 that becomes a status readout burns the only private channel you have
•
goal, reality, options, will: the conversation ends with the person choosing an action
•
a skip-level samples how a team is being led; using it to redirect work undercuts the manager
•
for complex work, intrinsic motivators outperform contingent rewards
•
pay and conditions cause dissatisfaction when bad but do not motivate when good
D. Feedback that changes behavior
•
situation, behavior, impact: when it happened, what was observed, what it caused
•
"you interrupted twice" is actionable; "you're dismissive" is a verdict
•
the giver reports the impact they saw; the receiver owns the intent, and the two rarely match
•
burying criticism between praise makes the praise suspect and the criticism invisible
•
care personally and challenge directly are independent axes, and both are required
•
caring without challenging is the most common failure, and it feels like kindness
•
challenging without caring is not honesty; it closes the channel it needed
E. Hard conversations and performance management
•
nothing in a review should be the first time the person hears it
•
open with the conclusion; a softened lede is heard as reassurance
•
diagnose skill, motivation or system first, because the three call for different responses
•
a verbal warning the person can reinterpret later is not a warning
•
run it honestly as one of the two; a plan designed to fail is a trust-destroying formality
•
the bill is paid by the team's standards and by your strongest people
F. Psychological safety and the culture that produces it
•
a shared belief the team is safe for interpersonal risk, not a belief that the team is comfortable
•
high safety with high standards is the learning zone; safety alone is the comfort zone
•
Edmondson's hospital study found better-led units reported *more* errors, inverting the original hypothesis
•
safety is set by what happens the first time someone brings the senior person a problem
•
pathological cultures hoard information, bureaucratic ones defend rules, generative ones serve the mission
•
Westrum-generative culture is a measured predictor of delivery and organizational outcomes
•
forming, storming, norming, performing; storming is a stage to work through, not a failure
•
absence of trust, fear of conflict, lack of commitment, avoidance of accountability, inattention to results
•
people commit to decisions they could argue against, not to decisions announced at them
•
dissent belongs before the decision; relitigating it afterwards is the failure mode
•
individual effort drops as group size grows unless each contribution stays visible
H. Hiring, interviewing and onboarding
•
the same questions plus an anchored rubric predicts performance; a free-form chat mostly measures rapport
•
sampling the actual work predicts strongly; brainteasers and pedigree predict weakly
•
written scores submitted before the debrief stop a senior voice anchoring the panel
•
"fit" quietly selects for sameness; state the values required and the perspective missing
•
an interviewer with no stake in filling the seat, because the hiring manager's urgency lowers the bar
•
an unresolved substantive doubt is a no; a mis-hire costs more than a missed hire
•
hire juniors for learning rate, seniors for demonstrated depth
•
a new hire deploying something small in week one is the ramp signal that matters
I. The four keys and what they measure
•
deployment frequency, lead time for changes, change failure rate, failed-deployment recovery time
•
the highest performers are faster *and* more stable, so the trade-off is a symptom of large batches, not a law
•
lead time for changes runs from code committed to code running in production, not from idea to launch
•
it is measured because batch size itself is hard to measure directly
•
the share of deployments that degrade service and need remediation, not the share of tickets that are bugs
•
restoring service quickly matters more than failing rarely, because failure is certain
•
they describe a delivery system; attributing them to one engineer is a category error
•
each key is gameable alone, but throughput and stability push against each other
J. Batch size, queues and flow
•
a smaller change is easier to review, faster to verify and cheaper to revert
•
defect rate, rework and elapsed time all scale with how much is in flight at once
•
a system loaded near capacity has wait times that grow non-linearly
•
limiting work in progress finishes things sooner; starting more finishes less
•
order work by value lost per week of waiting, not by size or by who asked loudest
K. Estimation, commitments and Brooks's law
•
an estimate is a distribution, a commitment is a promise; conflating them manufactures failure
•
early estimates are uncertain by multiples and narrow only as the work is actually done
•
the moment the date moves in your head is the moment to say it out loud
•
of scope, date and quality, scope is the one that can honestly move
•
adding people to a late project makes it later: ramp-up cost plus new communication paths
•
the law bites hardest on work that cannot be partitioned, which is the honest boundary of the claim
L. Meetings and group decisions
•
decide, discuss or inform; a meeting with no stated type defaults to status
•
a discussion with no decider produces consensus theatre or no decision at all
•
invite the smallest set that can reach the outcome; everyone else gets the notes
•
attention drifts to the trivial item everyone feels qualified to debate
•
imagining the failure before committing surfaces risks a status review never will
•
written rounds and explicit turns surface the quiet read the loudest voice buries
M. Technical strategy, debt and migrations
•
capture context, options, decision and consequences; the reasoning is the artifact, not the choice
•
build where the capability differentiates the product; buy the rest
•
frame tech debt to non-engineers in weeks of future delivery and incident risk, never in aesthetics
•
a big-bang rewrite discards years of absorbed bug fixes and delivers nothing until the end
•
migrate by routing traffic incrementally so every step is small and reversible
•
with no date to delete the old system you have permanently doubled the surface area
•
DORA finds an external change-approval board slows delivery without improving stability
N. Org design, Conway's law and Team Topologies
•
a system's structure mirrors the communication structure of the organization that built it
•
reshape the teams to produce the architecture you want, instead of fighting the org chart in code
•
teams able to test and deploy without depending on other teams is the strongest measured architectural predictor
•
stream-aligned, platform, enabling and complicated-subsystem
•
collaboration, X-as-a-service and facilitating, with collaboration deliberately time-boxed
•
a team owns what it can hold in its head; extra services do not fit just because headcount grew
•
report count trades depth of support against layers of hierarchy, and both sides cost something
•
a reorg resets relationships and context, and that dip belongs on the cost side of the decision
•
one person owns coordination and decisions, and does not debug
•
command, operations and communications are separate so the person fixing is not the person briefing
•
under-declaring costs more than a false alarm; escalation is cheap and delay is not
•
one shared timestamped document is what makes handover and the later postmortem possible
•
restore service first; root cause is a postmortem activity, not an outage activity
•
roll back unless rollback is impossible or riskier than the forward fix
•
executives wanting updates go to the comms lead, never to the person typing
•
ask what made the mistake easy, not who made it
•
"human error" ends the investigation exactly where it should begin
•
the signal looks obvious afterwards; judge the decision on what was knowable at the time
•
unowned follow-ups make the document the deliverable instead of the fix
•
deciding beforehand which events get a postmortem keeps the choice from becoming political
•
a five-whys line hides the several conditions that all had to align
Q. On-call, error budgets and toil
•
a rotation needs enough people that nobody is paged while exhausted
•
an alert no human can act on should be deleted, not tolerated
•
an SLO below 100% creates a budget of unreliability that funds change
•
what happens when the budget is spent is decided before it is spent
•
manual, repetitive, automatable, tactical work that scales linearly with the service
•
capping ops work protects the engineering time that would remove it
•
a service only one person can rescue is a single point of failure with a pulse
R. Stakeholders and upward communication
•
a project green until it is suddenly red has a reporting problem, not a schedule problem
•
escalate with the choices and the one you would take, not with the problem alone
•
stakeholders buy dates, risk and money; the architecture is your reasoning, not their decision
•
escalating jointly with the peer lead unblocks; escalating around them costs the relationship you still need
•
a dashboard anyone can read beats a status report only you can produce
•
the honest answer names what would have to move, rather than a flat refusal or a silent yes
S. Careers, ladders and staff-plus
•
a ladder is defined by the scope and ambiguity a person handles, not by tenure
•
promotion confirms someone is already operating at the level; it is not a bet on potential
•
cross-manager calibration exists so one manager's "exceeds" means what another's does
•
tech lead, architect, solver and right hand are four different jobs under one title
•
a mentor gives advice; a sponsor spends their own credibility on your behalf in a room you are not in
•
the coordination that makes a team function is often uncounted at promotion time and unevenly assigned
T. Measuring engineers without breaking them
•
a measure that becomes a target stops being a good measure
•
commits, lines and story points count activity, are trivially gamed, and ignore the system
•
features shipped is output; the change in user or business behavior is the outcome
•
satisfaction, performance, activity, communication, efficiency; never report one dimension alone
•
the original variance studies confounded environment with person and never established a per-person multiplier
U. Remote and async practice
•
a decision that exists only in a call did not happen for anyone who was not on it
•
DORA finds good internal documentation amplifies the effect of every other capability
•
with one person remote, either everyone dials in or the remote person is a spectator
•
a team spread past a few overlapping hours must change its process, not work later
•
visibility in an office gets mistaken for contribution when ratings are written
Keentune is not affiliated with or endorsed by the organizations whose documentation informs these maps.
Start practising Engineering Leadership
All about Engineering Leadership practice
All exam, test, and product names and trademarks are the property of their respective owners and are used here for identification and reference only. Keentune is independent study practice — not affiliated with, authorized, or endorsed by any of these organizations.
© 2026 SportaApp LLC