Writing archive
Writing organized by creation date.
Professional relationships are not a resource pool to be tapped, but a network of trust built slowly through real collaboration, measured help, and clear boundaries.
Part of the column “Recruiting & Professional Relationships” · Chapter 3
Responsibility isn't mindless overtime or mindlessly taking on work. This set of questions makes clear 'who decides, who executes, when to escalate, and where accountability ends.'
Part of the column “One-on-One Conversations” · Chapter 5
The job of a product overview is not to collect as many facts as possible, but to help readers build a shared question, form judgments, and understand what evidence is still missing within a limited time.
Part of the column “Product Judgment” · Chapter 2
The worst thing about growth talk is when it stays vague. Break 'I want to grow faster' down into situation, capability, evidence, and the next round of practice, so both manager and report know what to ask.
Part of the column “One-on-One Conversations” · Chapter 4
An engineering POC is neither a project secretary nor someone who covers for everyone else; the role exists to keep goals, commitments, risks, and decisions clear in cross-functional collaboration.
'I've been really busy' is a genuine feeling, but it isn't good enough as communication. These questions break 'busy' into scheduling, capacity, trade-offs, and commitments, so both managers and reports can ask them.
Part of the column “One-on-One Conversations” · Chapter 3
Self-use isn't about 'spending more time in the product'; it's a feedback system spanning real tasks, valid evidence, and verified fixes.
From daily and weekly reports to problem retrospectives: how to maintain baselines, record changes, judge impact, and turn data conclusions into verifiable action items.
Part of the column “Data Metrics Guide” · Chapter 5
Facing cross-functional requirements, how should an engineering POC divide work, surface risks, handle changes, and manage their own workload? A public FAQ for real-world collaboration.
A ready-to-copy metric dictionary template, plus public examples for completion rate, retention, conversion, error, experience quality, and feedback metrics.
Part of the column “Data Metrics Guide” · Chapter 4
Don't lay metrics flat on the dashboard: prioritize them by task relevance, scope of impact, actionability, and data trustworthiness, and choose what to watch at each stage.
Part of the column “Data Metrics Guide” · Chapter 3
A publicly reusable metric dictionary: from requests and users to tasks, explaining how availability, error, latency, performance, and feedback data should be defined, combined, and interpreted.
Part of the column “Data Metrics Guide” · Chapter 2
Metrics are not numbers on a report; they are the shared language a team uses to describe the same thing. Only after defining the object, event, denominator, and time can data participate in decisions.
Part of the column “Data Metrics Guide” · Chapter 1
When you don't know how to open or what to talk about, begin by defining the problem clearly. A question-and-answer checklist that managers and reports alike can follow.
Part of the column “One-on-One Conversations” · Chapter 2
Solve one problem per conversation, with each theme lasting 30 to 60 minutes. How to use this series, an overview of its topics, and the three closing principles.
Part of the column “One-on-One Conversations” · Chapter 1
A sense of achievement comes not only from results or praise from others; it also comes from keeping commitments, identifying with your profession, helping others, and believing that what you do matters.