The EM loop, which mixes people scenarios, delivery judgement, and enough retained technical credibility to lead engineers.
22 published across 7 topics.
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.
Act on the behaviour you can observe rather than waiting for a disclosure, open with what you have seen instead of a question they can deflect, then remove named work rather than offering sympathy. Check your own part in the load, and know the point where this stops being a management conversation.
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.
Deliver it as your own message tied to specific evidence, never as a committee's verdict you privately disagree with. If it is a surprise, treat that as your failure and say so, give one concrete thing that would change the next cycle, and refuse to trade a promise you cannot keep for their staying.
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.
Give a deliberately short brief, keep a written fact sheet you answer from truthfully, and tell the candidate more detail exists. Score which design-changing facts they surface and whether the work changes, not how many questions they ask, and give every candidate the same answers and a midpoint disclosure chosen by one rule.
A short, structured technical screen that asks a few questions resembling what the loop will probe, with pass criteria written in advance, run by someone able to follow up. Judge it by whether screen-passers clear the coding round more often without the pipeline collapsing, and count the candidate's time as a cost.
Treat thin evidence as a missing decision rather than a weak yes, because a hire made on impressions is a coin flip dressed as a process. Separate what was observed from what was inferred, find which required signals nobody actually tested, and close that gap with a targeted follow-up rather than overruling the room or rubber-stamping it.
Collect written evidence before anyone speaks, then work out whether the two disagree about what the candidate did or about where the bar sits, because only the second is yours to settle. Decide on the evidence against the competency, name the decision as yours, and fix whichever part of the loop produced the split.
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. Use this HIRING answer to show the decision, trade-off, and evidence rather than a memorised definition.
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.
Work out the shortfall in engineer-weeks so the gap is arguable, then rank the three on value at risk and on what other people committed on the strength of your date, take the trade-off to whoever owns it rather than deciding quietly, and stop the dropped item cleanly.
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.
Make the team convert the ask into a measured cost the current service imposes and a payback period, then test whether an incremental route reaches the same place. Say no on the arithmetic rather than on authority, and if you say yes, agree in advance what would make you stop.
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.
Measure where the coupling actually is before moving anybody, then cut boundaries around what a team can release without waiting on another. Price the transition honestly, name what your design makes worse, and be willing to say the coupling is architectural and no org chart will fix it.
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.
Own the decision publicly without pretending you authored it, find out individually what each person believes they have lost since the answers differ, then either win back real scope or say honestly that the team is now smaller than its ambitions. Quiet resistance costs you the team faster than the reorg did.