Proof of Work

Sourcing Compass is public to use and inspect. The other systems are private; their pages explain the problems and design choices behind them. A worked example shows how I approach a decision, and the writing develops the thinking behind it. Company and candidate details remain confidential.

A public tool and private systems

Building tools lets me turn recurring recruiting problems into something a team can inspect, question, and use.

• Sourcing Compass (public app and source): a first map of organisations, adjacent talent pools, and related titles to test before outreach. You can examine the map and the code.
• Interview Evaluator (private): transcript feedback on where an interviewer found evidence and where a line of questioning stopped short. The page explains the coaching purpose and offers a walkthrough.
• TA CentCom (private): a shared view of search constraints, ownership, and next actions. The page explains the operating decisions it supports.
• RishiOS (private): role- and level-specific evaluation, scorecard validation, and checks against recorded evidence. The page distinguishes current tools from the wider direction.

The project pages explain their scope and design choices. You can also explore the leadership context behind the work.

A worked decision: does this problem need another hire?

Adapted from an illustrative example in the revised edition of Raising the Bar. This is a demonstration of the reasoning, with no company or candidate details.

A team asks for a senior engineer because releases keep slipping. Before turning that request into a search, I would examine where the work gets stuck. In the example, two leaders have unresolved ownership of architecture decisions. Another engineer would inherit the same blockage.

I would first trace a recent stalled release: which architecture decision remained open, who had the information, and who had authority to decide? Then I would ask the leaders to make that ownership explicit and look again at the work. If the existing team can now make and carry out the decisions, the hiring request needs another examination. If decisions are clear and the work still requires expertise nobody has, or exceeds the team’s sustainable capacity, we have a stronger reason to hire.

The next step would be to decide whether that remaining need calls for an external hire, developing someone already there, or a narrower piece of specialist support. A hiring brief should name the capability the person would add and the authority they would have to use it.

That changes what the hiring conversation must establish. The example stops at the decision test; it makes no claim about a completed hire or a delivery improvement.

Explore how I develop the team’s hiring judgment.

Published thinking behind the practice

These pieces let you examine my reasoning and bring your own experience to it.

Planning the work and the talent it needs

• Scaling Talent Acquisition with Capacity Planning
• How Opportunity Cost in Hiring Impacts Business Outcomes

Developing hiring judgment

• Hiring for Great vs. Hiring for Role Fit
• Why Interviewer Insight Still Matters in Tech Hiring
• Speed vs. Accuracy: What Most HRBPs Get Wrong

Building teams and systems

• Machines Run the Repeatable Steps, People Make the Calls: the hiring-system rebuild behind my TA Operating System framework, including early evidence and lessons from measurement.
• Vibe Coding in Talent Acquisition
• How the Engineering Talent Profile Has Evolved
• What Happens When Everything Fails at Once? Leadership.

Founder Hindsight brings together founder and operator accounts of people decisions, with linked sources and my interpretations. Raising the Bar develops my approach to recruiting through worked examples and practical tools. Both are invitations to examine the choices behind the work.