Is that your pubkey in my ~/.authorized_keys, or are you just happy to see me?

ljrk

Quiet Influence: A Guide to Nemawashi in Engineering

• 🌳 The roots of the concept — Nemawashi is a Japanese term that literally translates to “going around the roots.” In gardening, it refers to the process of carefully digging around a tree and preparing the soil before transplanting it. In business, it is the practice of laying the groundwork for a proposed change or decision by speaking with stakeholders individually before bringing it to a public forum.
• 🤝 Meetings are for ratification, not debate — The author argues that big decisions should essentially be made before the formal meeting starts. By utilizing Nemawashi, the official meeting becomes a ceremony to confirm a consensus that has already been built, rather than a high-stakes environment where ideas risk being shot down.
• 🏗️ Essential for Engineering Strategy — This technique is a superpower for Staff+ engineers and leaders. When introducing an Architecture Decision Record (ADR), an RFC, or a re-org, “quiet influence” ensures that key influencers understand the proposal and have had their concerns addressed privately. This prevents the gridlock often seen in large technical review committees.
• 🛡️ Saving face and psychological safety — debating controversial points in a large group can trigger defensiveness. Addressing friction in 1:1 settings allows people to voice dissent or ask “stupid questions” without fear of judgment. It also prevents the awkwardness of a stakeholder having to publicly reject a proposal, allowing everyone to maintain professional dignity.
• 🐢 Slow down to speed up — While holding multiple individual conversations feels inefficient compared to calling one big meeting, it is actually faster in the long run. It prevents the “meeting about the meeting” loop and ensures that once a decision is made, it actually sticks because the necessary alignment is genuine.

Diagnose Before You Delegate

• 🩺 The premature delegation trap — Leaders often feel the urge to immediately assign a problem to someone the moment it arises. Subbu argues that “delegating without diagnosing” is a recipe for failure, as it forces the team to chase vague symptoms rather than addressing the core issue.
• 🧐 Problem shaping vs. Problem solving — There is a distinct difference between shaping a problem and solving it. A leader’s responsibility is to shape the problem—defining the boundaries, context, and impact—before asking a team to solve it. Skipping this step leads to “solutioneering” without direction.
• 📉 The cost of ambiguity — When you delegate a raw, undiagnosed issue, you aren’t empowering your team; you are burdening them with ambiguity. This results in wasted cycles, increased frustration, and often, the wrong solution being built for the wrong problem.
• 🛑 Stop “drive-by” management — Effective leadership isn't about tossing commands out the car window while driving past. It requires stopping, getting out of the car, looking under the hood to understand the nature of the breakage, and then calling the right mechanic.
• 🧠 Context is the precursor to autonomy — We often hear that good leaders give teams autonomy. However, autonomy without context is chaos. Diagnosis provides the necessary context so that when you finally do delegate, the team can act with true agency and precision

You Have Too Many Metrics

• 📊 Metrics are a “Check Engine” light — The article argues that engineering metrics should be treated like a car's check engine light. They are useful for alerting you that something might be wrong (e.g., velocity dropping significantly), but they cannot tell you what is wrong or how to fix it. You still need to open the hood—talk to the team—to diagnose the actual issue.
• 🛑 Don't use metrics for performance reviews — Using quantitative metrics (like lines of code or number of PRs) to judge individual engineer performance is dangerous. It incentivizes the wrong behaviors (gaming the system) and destroys team morale. Metrics are for understanding the system, not for ranking the people.
• 🎯 The inevitability of Goodhart’s Law — The moment a measure becomes a target, it ceases to be a good measure. If you tell a team you are measuring them on ticket closures, they will close more easy tickets and ignore the hard, important ones. Leaders must be vigilant about how observing a metric changes the behavior of the team they are observing.
• 📉 Output vs. Outcome — There is often a disconnect between engineering activity (output) and business value (outcome). High velocity doesn't matter if you are shipping features nobody wants. Managers need to be careful not to confuse “being busy” (high metric activity) with creating value.
• 🕵️ Quantitative data requires qualitative context — Numbers on a dashboard are stripped of context. A “slow” week might mean the team was stuck in meetings, or it might mean they were solving a critical, complex architectural problem that doesn't show up on a JIRA chart. You must pair the data with the narrative to get the truth.

7 Phrases I use to make giving feedback easier for myself

• 🤝 Establish positive intent first — Feedback often triggers a “fight or flight” response because the recipient feels attacked. To bypass this, start with: “I’m saying this because I have high expectations and I know you can reach them.” This signals that the feedback is a form of investment in their growth, not a punishment.
• ⚖️ Calibrate the weight of the feedback — Miscommunication happens when a direct report thinks a minor suggestion is a mandatory order, or vice versa. Use phrases like “This is a nit” for minor details, or “This is a blocker” for critical issues. Clearly labeling the severity prevents the team from wasting energy on low-value changes.
• 🚫 Define what you are NOT saying — When hearing criticism, our brains tend to catastrophe and assume the worst. To stop the spiral, use the phrase: “To be clear, I’m not saying [X], I’m saying [Y].” For example, “I’m not saying your design is bad, I’m saying it doesn't solve the specific user problem we defined.”
• 🕵️ Turn judgment into curiosity — Instead of assuming negligence or incompetence, ask: “Walk me through your thinking on this.” This phrase (or “Help me understand...”) allows the recipient to explain their context. You might discover they had a valid reason for their decision, or you might expose a flaw in their logic without being aggressive.
• 🔮 Frame feedback as future protection — To make critical feedback feel helpful rather than hurtful, frame it as preparation for a higher-stakes environment. Use the phrase: “I’m mentioning this now so you don’t get blindsided in the big meeting next week.” This positions you as an ally helping them avoid public failure.

The Reality of Tech Interviews in 2025

• 📉 The power dynamic has flipped — The article highlights a stark transition from the “candidate-driven” market of the recent past to an “employer-driven” one. Companies now receive hundreds of applications for single roles, allowing them to be slower, pickier, and less responsive. The days of rapid offers and bidding wars are largely paused.
• 🎢 The “Bar” is a variable, not a constant — We often think of the “hiring bar” as a fixed standard of engineering quality. Gergely argues that the bar is actually a function of supply and demand. When applicant volume floods the funnel, companies raise the bar arbitrarily (adding rounds, asking harder questions) simply to reduce the numbers, not necessarily to find better talent.
• 🧩 The Great Bifurcation — The industry is split into two distinct “games.” On one side are the Algorithm Companies (Big Tech/FAANG) that require intense LeetCode/DSA prep. On the other are Real World Companies using practical assessments (pair programming, debugging). Candidates often have to choose which game to study for, as preparing for both simultaneously is exhausting and inefficient.
• 🎲 Skill is necessary, but luck is dominant — Passing an interview is not just about competence; it is heavily influenced by randomness. Factors like the interviewer’s mood, the specific question drawn, or whether the interviewer had a good lunch play a massive role. A rejection is often a signal of bad timing or bad luck rather than bad engineering.
• 👻 The rise of “Ghosting” — The candidate experience has degraded significantly. Because recruiters are overwhelmed by volume, “ghosting” (cutting contact without explanation) has become the norm, even for candidates who have made it past the initial screens. Silence is the new rejection letter.

That’s all for this week’s edition

I hope you liked it, and you’ve learned something — if you did, don’t forget to give a thumbs-up, add your thoughts as comments, and share this issue with your friends and network.

See you all next week 👋

Oh, and if someone forwarded this email to you, sign up if you found it useful 👇