Writing
Technology, work, leadership, and field notes.
“Last updated” prefers the update date; posts never updated are sorted by publication date.
The Business Model Canvas from an enterprise investment class, noted for myself: what each of the nine boxes is, the question each box must answer, and why the line 'all of them must be satisfied for a project to succeed' depends on the company's stage.
A hands-on companion to the Five Lenses method: four scenarios — interview, promotion, reporting, and cross-team collaboration — show how to apply the structured tools and the Five Lenses to real problems.
Part of the column “Thinking Practice” · Chapter 4
Condensing the judgments that have recurred over the past few years in management, collaboration, and decision-making into a single master summary told just once: judgment, boundaries, alignment, context, closed loop, resources, team, and retrospective — each pointing to one expanded article.
A note on a distinction: the business model canvas is 'made for yourself,' the startup pitch is 'told to others,' and investor due diligence is 'others scrutinizing you'; the three differ completely in purpose, focus, and framing — don't mix them up.
This site is being rebuilt from an old static blog into a personal publication about technology, work, and life — and it also records the trade-offs made along the way.
From a temporary SSH direct connection, to accommodating phones and family, and finally converging on sing-box as a maintainable return-to-China network setup.
A farewell, reflection, and word of thanks at the end of an eight-and-a-half-year career journey.
Distill scattered thoughts into a document that can be discussed and acted on: tools handle the organizing, people handle the judgment.
Part of the column “Documentation & Knowledge” · Chapter 3
Technical planning is not a project list. At its core it is two things: understanding the business you serve (business analysis) and understanding the gap and level against competitors (competitive analysis), then linking them into a causal chain of goals, trade-offs, and execution.
Part of the column “Technical Systems” · Chapter 1
Starting from saying 1, 2, 3 clearly, practice listening, restating, answering, and self-review, so that messy information gains an actionable structure.
Part of the column “Thinking Practice” · Chapter 2
Choosing makeup doesn't require memorizing shade numbers or brands first: observe your skin tone, lightness, and how your skin feels that day in natural light, then narrow your choices down to colors and textures that suit you.
From skin prep to finishing touches, a practical full-makeup routine that leans natural and emphasizes long wear and bone-structure definition.
A responsible referral is not about prompting an application, but about helping both sides gain enough truthful information to judge whether it is worth getting closer.
Part of the column “Recruiting & Professional Relationships” · Chapter 2
A ready-to-use gifting guide: first confirm the person and the occasion, then narrow the choices across three categories — generic, custom, and experience.
Recruiting branding is not about polishing a job posting; it is about making the right people believe: the work is worth doing, the team has a chance to make it happen, and they can push it into reality together with their peers.
When facing a long list of tasks, problems, and opinions, first define the standard of judgment, then find the few things that truly rank at the top.
Part of the column “Thinking Practice” · Chapter 1
Insecurity comes from the environment and also from comparison. First identify the source, then adjust expectations, extend the time horizon, and pull attention back from 'how others are doing' to 'what I should practice.'
Part of the column “One-on-One Conversations” · Chapter 13
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
A personal reading record from 2021 to 2023: what I read, how I keep notes, and a few reflections I still haven't fully worked out.
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
Six days in June 2023: Ginza, Shibuya, Yokohama, and Kamakura, plus density, walking, and "why is area priced separately".
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.
Part of the column “Building Teams” · Chapter 4
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.
Part of the column “Building Teams” · Chapter 2
Growth paths are not job-level checklists but three expanding responsibilities: completing tasks, owning problems, and enabling others to do important work.
Part of the column “Building Teams” · Chapter 5
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.
Part of the column “Building Teams” · Chapter 1
Fourteen days in Jakarta in February 2023: a city folded and cut apart, where high-rises and street stalls each live out their own everyday.
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
The worst thing for a capability model is to be treated as fog. Break 'where am I now, where are the gaps, where do I go next' into questions you can measure yourself, rather than relying on others to label you.
Part of the column “One-on-One Conversations” · Chapter 8
From the resume and fundamentals to the project presentation: an interview is not about guessing a standard answer, but about letting people see your facts, judgment, learning style, and way of collaborating.
Structure isn't about applying a template; it's about making problems, evidence, trade-offs, and decisions checkable by others. A ready-to-use training and questioning checklist.
Part of the column “One-on-One Conversations” · Chapter 7
Product sense isn't guessing at requirements. A ready-to-use list of talking points, from two angles: how engineers should understand the product, and what product managers actually do.
Part of the column “One-on-One Conversations” · Chapter 6
From completing requirements to taking part in planning, how engineers place technical implementation between user problems and business outcomes.
Part of the column “Product Judgment” · Chapter 1
Don't treat cooking as a test of willpower: with a small set of fixed choices, turn shopping, prep, cleanup, and unexpected changes into a sustainable routine.
A team is not simply the sum of its headcount and abilities. Real growth means forming, over time, more reliable collaboration, transferable experience, and the capacity to keep solving problems when circumstances change.
Part of the column “Building Teams” · Chapter 3
Don't judge a job by title, busyness, or short-term evaluation. Look at whether it leaves portable changes in how you understand, spend time, and execute.
Part of the column “Growth & Self-Assessment” · Chapter 2
Recruiting is not just about filling a vacancy; it is about continuously clarifying what the team needs and can offer, and calibrating judgment with every choice.
Part of the column “Recruiting & Professional Relationships” · Chapter 1
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
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
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
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.
A practical way to write technical documents: state the conclusion and problem clearly first, then use the right structure to carry the plan, progress, and details.
Part of the column “Documentation & Knowledge” · Chapter 1
The value of an engineering retrospective is not in retelling what happened or blaming individuals, but in turning an experience into improvements that can be verified, maintained, and reused.
Turn technical sharing from a regular talk into a knowledge-collaboration system that connects topic selection, research, discussion, and consolidation.
A mentor's value lies not in planning everything for the new hire, but in jointly building goals, feedback, and a rhythm of gradually stepping back; a workable 90-day plan makes this traceable.
Part of the column “Building Teams” · Chapter 6
An entry page is not a pile of links, but the shared memory a constantly changing project leaves for its team: it helps readers enter by task, judge whether information is still valid, and find the people responsible for maintaining it.
Part of the column “Documentation & Knowledge” · Chapter 2
An old signpost written for frontend beginners: information gathering, study logs, algorithm practice, interviews, and internships are all just the beginning.
An old case from a Double Eleven shopping scenario: before rushing to a solution, first identify the problem the user is actually facing.
An index of interview and engineering fundamentals compiled after the spring 2018 job search; keeping it as a reminder that interview questions are never just interview questions.
A sci-fi short written in early university: when a bug in a two-dimensional network gains three-dimensional knowledge, what it loses is not ignorance but the ability to act.