Tags
Writing, research, projects, and photos around “Collaboration”.
A research-design and protocol paper: reframing data measurement from what belongs on the dashboard into a recomputable, reviewable, decision-supporting collaboration protocol, with minimal mechanisms for definitions, measurement units, metric tiering, dictionaries, and retrospectives.
Read summaryWhen 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
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.
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
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
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.
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
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
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
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
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
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
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.