About Calibrate
While writing this Field Guide, I kept running into the same problem: people aren't learning because the workplace makes honest feedback nearly impossible. Colleagues hold back. Managers soften. And most have awareness gaps: we don't know what we don't know.
In the book, I tell a story about someone whose career shifted after a difficult but honest peer review. What I didn't include was the flip side. One year, I was late kicking off peer reviews. An engineer was hounding me to get it started because she really believed in the process. In the end, she got back vague praise, no specifics, nothing she could act on. It sucked, so I had to find some non-peers to review some of her work and get her something useful.
So, as part of this project, I built Calibrate. You share a link with peers. They answer structured questions about their experience working with you. You own the results. Nobody is obligated to do it; do with the results what you will.
I co-founded a company called FirstWho, which builds rubrics to help organizations make better hiring decisions. For Calibrate, I adapted that approach using a rubric drawn directly from this book.
The surveys come in versions aligned to different roles: engineer, senior engineer, manager, product manager, product designer, user researcher, and stakeholder. Rather than asking people to rate your skills, the questions focus on their experience: not "How good is this person at X?" but "How often have you observed X in your interactions?" This helps peers respond more accurately based on their experience, not their judgment of you.
There are bound to be bugs and gaps. I'll iterate as I get feedback from actual users.
Below is a table showing the rubric dimensions and which chapter each connects to.
Rubric Dimensions
| Dimension | Type | Chapter |
|---|---|---|
Domain Fluency You cannot own problems or make sound technical decisions without understanding the real-world context your software operates in. | Competency | The Job |
Impact Awareness The bridge between doing and mattering; without this, you measure tickets closed rather than problems solved. | Competency | The Job |
Task Completion Ideas without execution are worthless, and the ability to reliably move work from "in progress" to "done" is non-negotiable. | Competency | The Job |
Cross-Functional Communication Software is built by teams of different specialists, and your effectiveness depends on how well you translate across them. | Competency | The People |
Requirements Questioning Knowing when to challenge what's being built versus execute reliably separates engineers who shape outcomes from those who just take orders. | Competency | The Job |
Written Documentation Making reasoning visible and durable enables honest disagreement and prevents the same mistakes from being repeated. | Competency | The People |
PR & Review Quality Code review is where candor happens at the micro level: giving honest, categorized feedback and receiving it without defensiveness. | Competency | The Work |
Research Execution The antidote to solutionism is reducing uncertainty before committing resources through timeboxed, question-driven investigation. | Competency | The Work |
Working with Product The most critical cross-functional relationship is where problem ownership is negotiated daily. | Competency | The People |
Tool Fluency Fighting your tools steals energy from harder problems, and foundational efficiency compounds over a career. | Competency | The Work |
Working with Design For user-facing work, early engagement with design prevents expensive late rework and produces better outcomes. | Competency | The People |
Reality-Facing You cannot give honest feedback, make sound strategy, or demonstrate humility without first facing what is actually true. | Attitude | The Job |
Transparency About Struggle Surfacing problems early is how humility shows up at work; hiding struggles is the path to losing your job and your team's trust. | Attitude | The Job |
Team-First Collective success over individual metrics means credit-sharing, helping teammates, and course-correcting together. | Attitude | The Job |
Completion Drive The killer instinct for finishing transforms domain knowledge and good intentions into actual shipped value. | Attitude | The Job |
Outcome Orientation Caring about whether work solved the problem, not just whether it shipped, is what separates empowered engineers from ticket-takers. | Attitude | The Cadence |
Constructive Disagreement Healthy teams argue about the work directly, then commit; theatrical objections and back-channel complaints corrode trust. | Attitude | The People |
Asking for Help Treating help-seeking as normal rather than weakness enables team efficiency, learning, and prevents isolated failures. | Attitude | The Job |
Appropriate Skepticism Not accepting requirements, AI output, or conventional wisdom without thought prevents wasted effort, but paralysis is equally costly. | Attitude | The Robots |
Respect for Other Functions You do not know everything, and valuing the expertise of product, design, research, and ops is the foundation of collaboration. | Attitude | The People |
Early Engagement Showing up when input can still change direction prevents the frustration of discovering problems after decisions are frozen. | Attitude | The People |
Evidence-Seeking Grounding decisions in data, research, and incidents rather than opinion or seniority produces better outcomes and earns trust. | Attitude | The People |
Growth Orientation Actively seeking stretch and challenge rather than coasting after "good enough" is what separates careers that plateau from those that compound. | Attitude | The Heights |
Domain Fluency
CompetencyYou cannot own problems or make sound technical decisions without understanding the real-world context your software operates in.
Impact Awareness
CompetencyThe bridge between doing and mattering; without this, you measure tickets closed rather than problems solved.
Task Completion
CompetencyIdeas without execution are worthless, and the ability to reliably move work from "in progress" to "done" is non-negotiable.
Cross-Functional Communication
CompetencySoftware is built by teams of different specialists, and your effectiveness depends on how well you translate across them.
Requirements Questioning
CompetencyKnowing when to challenge what's being built versus execute reliably separates engineers who shape outcomes from those who just take orders.
Written Documentation
CompetencyMaking reasoning visible and durable enables honest disagreement and prevents the same mistakes from being repeated.
PR & Review Quality
CompetencyCode review is where candor happens at the micro level: giving honest, categorized feedback and receiving it without defensiveness.
Research Execution
CompetencyThe antidote to solutionism is reducing uncertainty before committing resources through timeboxed, question-driven investigation.
Working with Product
CompetencyThe most critical cross-functional relationship is where problem ownership is negotiated daily.
Tool Fluency
CompetencyFighting your tools steals energy from harder problems, and foundational efficiency compounds over a career.
Working with Design
CompetencyFor user-facing work, early engagement with design prevents expensive late rework and produces better outcomes.
Reality-Facing
AttitudeYou cannot give honest feedback, make sound strategy, or demonstrate humility without first facing what is actually true.
Transparency About Struggle
AttitudeSurfacing problems early is how humility shows up at work; hiding struggles is the path to losing your job and your team's trust.
Team-First
AttitudeCollective success over individual metrics means credit-sharing, helping teammates, and course-correcting together.
Completion Drive
AttitudeThe killer instinct for finishing transforms domain knowledge and good intentions into actual shipped value.
Outcome Orientation
AttitudeCaring about whether work solved the problem, not just whether it shipped, is what separates empowered engineers from ticket-takers.
Constructive Disagreement
AttitudeHealthy teams argue about the work directly, then commit; theatrical objections and back-channel complaints corrode trust.
Asking for Help
AttitudeTreating help-seeking as normal rather than weakness enables team efficiency, learning, and prevents isolated failures.
Appropriate Skepticism
AttitudeNot accepting requirements, AI output, or conventional wisdom without thought prevents wasted effort, but paralysis is equally costly.
Respect for Other Functions
AttitudeYou do not know everything, and valuing the expertise of product, design, research, and ops is the foundation of collaboration.
Early Engagement
AttitudeShowing up when input can still change direction prevents the frustration of discovering problems after decisions are frozen.
Evidence-Seeking
AttitudeGrounding decisions in data, research, and incidents rather than opinion or seniority produces better outcomes and earns trust.
Growth Orientation
AttitudeActively seeking stretch and challenge rather than coasting after "good enough" is what separates careers that plateau from those that compound.