Tags
Writing, research, projects, and photos around “Work & Leadership”.
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 framework paper that advances structured thinking from the generic expression of "conclusion first, mutually exclusive and collectively exhaustive" into a four-stage problem-location method — Structure → Surface connections → Infer root problem → Find solution — with the causal, duality, dialectical, position, and interest lenses at its core, offering a testable training protocol and its boundaries of use.
Read summaryA theoretical synthesis, conceptual model, and application framework: it redefines motivation from "whether someone has drive" into a situated process of "whether motivation is generated, whether it can be converted into behavior, and whether it can be sustained," integrating self-determination theory, expectancy-value, goal setting, self-efficacy, and behavior models; bringing in perspectives from developmental psychology, business management, and organizational and occupational psychology to propose a three-layer "Situational Motivation Model" with a "growth axis," which it concretizes in the workplace into six components — task, goal, incentive, feedback, development path, and leadership/relationship — connecting to measurable outcomes such as engagement, commitment, performance, burnout, and turnover, introducing the enterprise life cycle as an enterprise-level moderating variable, and ultimately yielding nine falsifiable laws of motivation.
Read summaryA research-design and protocol paper: it proposes a material-organization and risk-annotation protocol aimed at safety actions, covering intimate and general interpersonal relationships, and defines AI's role as a structured co-pilot.
Read summaryA position paper: functional lines were efficient in an era of highly specialized work; once tools lower skill barriers, organizations should be redesigned around end-to-end business capability. It provides the mechanism, a spectrum of organizational forms, judgment signals, the two Chinese and American starting points, talent needs, and a falsifiable pilot protocol.
Read summaryA research-design and protocol paper proposing a safety-action-oriented framework for organizing material and annotating risk in workplace settings, covering top-middle-bottom three-tier safety, power structures, horizontal competition, authority-responsibility misalignment, career safety, career development, and occupational mental health.
Read summaryA novel. Lu Zhao grew up in the Ming Cult of the Western Regions, wearing a longevity lock inscribed with "Long Life." At nineteen she is ordered to enter Tong Pass, delivering messages, guiding the way, and saving people amid the chaos of war — can an ordinary person avoid having her life decided for her by her sect, her family, and history?
View projectA novel. Cradling three-month-old Shen Le, Xiban walks into the sand sea, wanting only to bring this child through the trade route alive. A wish never guarantees happiness; it only leaves the responsibility to those who come after the wish is fulfilled.
View projectA 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
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
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
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
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.
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
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.
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
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.
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.
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
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
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
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.
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.
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.
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
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 old case from a Double Eleven shopping scenario: before rushing to a solution, first identify the problem the user is actually facing.