The EM loop, which mixes people scenarios, delivery judgement, and enough retained technical credibility to lead engineers.
12 published across 7 topics.
Engineering management fundamentals58 short answers on one page, for revising rather than studying.One-on-ones, motivation and retention, feedback delivery, and building psychological safety.
One-to-ones are the engineer's time for the things that do not fit anywhere else, not a status meeting. Feedback lands when it is specific, close to the event, about behaviour and its effect, and carries a request. Growth is owned by the engineer; the manager owns opportunity, honest signal and air cover.
Separate the conversation about why from any conversation about money, find out whether the cause is something you can genuinely change, be honest that a counter-offer rarely fixes a non-financial reason, and treat the knowledge and morale consequences as work that starts the same week.
Managing an underperformer, career frameworks, promotion cases, and handling a top performer's stagnation.
Diagnose the cause before acting — skill, will, unclear expectations, or an environment or health problem you can remove — then give specific behavioural feedback, write down one expectation with a date, and make sure a formal performance plan, if it becomes necessary, is never a surprise.
Define senior as a scope of autonomy and influence rather than a tenure or a skill list, agree the two or three gaps in writing, engineer assignments that produce evidence of exactly those, keep a running log of it, and say plainly what you control and what calibration does.
Designing a loop, calibrating a bar, structured scoring, and defending a hire or no-hire decision.
Work backwards from the four or five competencies the role genuinely needs, map each to exactly one round so nothing is measured four times, score against shared behavioural anchors, require written feedback before the debrief opens, and treat both false negatives and candidate experience as data you owe yourself.
Work the funnel backwards from three accepted offers to see how much top-of-pipeline you need, own sourcing and referrals rather than waiting on inbound, treat speed and an honest pitch as your two real advantages, and protect the bar by moving the date instead of the standard.
Roadmap commitments, capacity planning, dependency management, and communicating a slip upward.
Reject the choice between a fabricated date and no answer. Ask what decision the date serves, separate known work from assumed and unknown work, give a range with its confidence and assumptions attached, buy the missing information with a timeboxed spike, and offer to fix scope or date but not both.
Measure where the time is going before setting any split, publish the allocation as a policy with a rationale rather than a percentage you invented, route interrupts through one named person, and justify debt work by the delivery cost it removes instead of asking for a refactoring sprint.
Staying credible without coding daily: reviewing designs, arbitrating disputes, and managing tech debt.
Stay current on failure modes, cost and architecture rather than on syntax, and keep off the critical path. When you disagree with a design, declare whether you are giving input, asking a question, or making a decision — because unlabelled opinions from a manager are heard as instructions.
Team topology, cross-team alignment, managing your manager, and driving change without authority.
Ask for an outcome rather than for people, price the status quo in the currency the decider uses, and pre-wire the case before the forum. When someone bypasses you, treat it as evidence your intake is too slow rather than as an authority problem, and fix the front door first.
Situations to handle live: two senior engineers in conflict, an attrition wave, a project you inherit failing.
Name the delivery impact concretely, then look for the structural cause — most such conflicts are an unadjudicated design or ownership dispute wearing a personality mask. Hear both separately, decide what they cannot, set observable expectations with a review date, and separate them only as a last step.
Verify the position from working software rather than opinions, re-baseline once with evidence and options attached, tell your leadership early and without blaming your predecessor, protect the team from the fallout, and fix the reporting mechanism that let a red project look green.