When business growth slows, teams get anxious together. First set the tone of 'respond positively, analyze the problem, solve the critical path,' then talk through what's going wrong item by item.
Part of the column “One-on-One Conversations” · Chapter 12
An uncompressed question bank: prepare promotion materials, interview answers, and stage reviews item by item across business, technology, team, individual judgment, and organizational capability.
Career growth isn't just shipping more requirements—it's gradually expanding your responsibility for defining problems, making trade-offs, and collaborating.
Planning and retrospective are not about completing tasks. From the difficulty of setting goals, to methods for retrospective, and on to orienting around your own growth — a complete list of topics.
Part of the column “One-on-One Conversations” · Chapter 11
The purpose of developing a team is not to pour experience into everyone, but to make judgment, collaboration, and responsibility things that can be practiced, given feedback on, and passed on.
When an existing bench has failed or you need to start over, rebuild responsibility, standards, and development mechanisms first — not just redraw a division-of-labor chart.
Growth paths are not job-level checklists but three expanding responsibilities: completing tasks, owning problems, and enabling others to do important work.
What we call self-iteration is not endlessly pushing yourself to go faster; it is seeing your goals clearly, observing results, adjusting your actions, and continuously recalibrating amid uncertainty.
Part of the column “Growth & Self-Assessment” · Chapter 3
Fifteen days in May 2023: working in another time zone while driving, refueling, parking, and keeping accounts. The deepest impression was not the sights but the jet lag and the expense.
A good question is not a clever way of asking, but turning a vague sense of discomfort into something verifiable, discussable, and actionable; this is a set of daily exercises for work, learning, and review.
Part of the column “Thinking Practice” · Chapter 3
Disaster recovery and review are healthy redundancy; the horse race caused by grabbing resources, grabbing projects, and unclear authority pushes an organization into zero-sum exhaustion.
The resource curse isn't having too much money or too many people; it's resources making goals more granular, structure heavier, and low-quality decisions more common, until the organization loses the ability to find and solve high-ROI problems.
One-on-ones at work are not counseling. Break anxiety into "what you can control and what you cannot"; talk through perception first, then concrete pressures and working conditions.
Part of the column “One-on-One Conversations” · Chapter 10
Functional lines once made specialized capability run efficiently; once tools lower workflow barriers, organizations should redesign around end-to-end business capability rather than cling to historical divisions of labor.
Part of the column “Technical Systems” · Chapter 5
Sync the officially confirmed objective facts first, without covering up problems; then explain goals, stability, and the new ways of collaborating separately to superiors, the team, and collaborators.
Headcount ratios are only a dynamic concept. What matters more is aligning goals, markets, and resource constraints in time when expanding, contracting, or changing plans.
Part of the column “Engineering Collaboration” · Chapter 4
The core of a 1-on-1 is helping managers and reports understand each other's goals and needs; authorization must follow information and role boundaries rather than mistaking context for transferred decision rights.
A multi-region system can neither cram every difference into a single core nor rebuild everything for each region. The key is to identify stable boundaries, preserve extension points, and clarify module ownership.
Part of the column “Technical Systems” · Chapter 4
The goal of effective sync is not to send out everything you know, but to give a specific reader, at the right time, the information needed to judge, collaborate, or act.
The most expensive cost of remote collaboration is often not the time difference but the repeated loss of context. Clear closed-loop responsibility, asynchronous documentation, and limited overlap time make collaboration more stable.
Part of the column “Engineering Collaboration” · Chapter 2
Resource pressure is not something a call to "try harder" can fix. The team needs to reduce commitments, risks, and complaints back to facts, and make trade-offs openly.
Part of the column “Engineering Collaboration” · Chapter 3
Time management isn't about packing your calendar full; it's about clarifying your commitments—and what you won't do right now—based on role, value, and opportunity cost.
Most project conflicts are not about someone failing to cooperate, but about goals, facts, or decision authority never being made explicit. Only by clarifying these three things first can disagreements return to something solvable.
Part of the column “Engineering Collaboration” · Chapter 1
Every role owns its own delivery, and everyone shares accountability for production outcomes. A quality loop depends on monitoring, fast containment, precise fixes, and retrospectives.
Good collaboration is built on trust, shared information, and solving problems together; when goals conflict, don't make promises privately—escalate with complete information to align.
Good standards don't turn every step into an approval; they make the key handoff points — where distortion, rework, and accidents are most likely — visible, discussable, and reusable.
Part of the column “Technical Systems” · Chapter 3
Motivation is not manufactured through slogans or pressure. What a manager can do is distinguish whether the problem stems from the environment, the role, the rewards, or the person's own state, and offer honest but limited support.
Part of the column “Engineering Collaboration” · Chapter 5
Managers don't need to review every line of code, but if they drift away from front-line detail they lose the ability to judge risk, cost, and what is really blocking the team; the point is to build sampling-based understanding, not micro-control.
Code decay rarely comes from any single moment of bad writing; it comes from local changes repeatedly bypassing shared boundaries. What truly needs maintaining is the consistency between design and collaboration.
Part of the column “Technical Systems” · Chapter 2
Technology can't manufacture a selling point out of thin air, but engineers can still help the team understand users more precisely, shorten validation cycles, and turn implicit constraints into choosable problems.
When entering an unfamiliar business or system, don't rush to start from a local solution. First map the users, the process, inputs and outputs, key constraints, and value, so you know what to ask.
Frontline management is not about doing a bit more work for the team; it is about continuously producing better judgment, predictable delivery, and a collaboration system that can repair itself.
Potential is not a label drawn from a résumé or a single performance. Rather than judging whether someone is "smart enough," observe how they learn, act, think, and recover from setbacks.
Part of the column “Growth & Self-Assessment” · Chapter 1
Communication is a broad topic, but it can be made concrete. Starting with 'clarify first, then give feedback, then commit,' plus a complete list of questions for workplace communication.
Part of the column “One-on-One Conversations” · Chapter 9