Assessing engineers without a development background often feels like guessing who is "smart" or counting tickets, leading to unfair evaluations and eroded trust. To do this correctly, you must stop looking for a single magic number and start treating performance as a coherent picture, not a single metric. This guide covers how to combine results, activity signals, and peer insight to build a defensible evaluation without writing a line of code.
1. Define Performance: Results + Sustainability
Before you look at a dashboard, settle one question: What does "performing well" actually mean? It has two layers:
- Results (Lagging): What changed for the customer or system?
- Sustainability: Did they burn out the team or leave brittle code behind?
Andrew Grove defines a manager's output as the output of their organization. Similarly, an engineer's value is the durable value they help the team produce, not how busy they look.
2. Use the Black Box Model
Since you cannot read the code, treat engineering as a black box where you can observe Inputs, Process, and Outputs.
- Inputs: The complexity of the problem given.
- Process: How they clarify requirements and collaborate.
- Outputs: The features shipped and incidents prevented.
You don't need to see the implementation detail to ask: "Given the inputs, was the process thoughtful and the output valuable?"
3. Triangulate the Three Pillars
A fair review never relies on one source. You need to triangulate between three signals.
- Results: The business outcome (Lagging).
- Activity: The traces in Jira/GitHub (Leading).
- Peer Feedback: The context from the team.
The Pattern Match:
- Strong results + Steady activity + Positive peer feedback = High Performance.
- Weak results + Low activity + Peer concerns = Underperformance.
- Mixed signals (e.g., high activity, low results) = Investigate.
4. Treat Activity as a Clue, Not a Score
Activity metrics (PRs, ticket counts) are dangerous if used as a leaderboard.
The Failure Mode: If you rank people by "story points," they will inflate estimates and slice work unnaturally small.
The Fix: Use activity stats as early warning signals, not verdicts. A drop in activity might mean they are blocked, or it might mean they are doing high-value "glue work" like mentoring. The metric tells you where to look, not what to think.
5. Collect Structured Peer Feedback
Peer feedback is the only way to see "invisible" work like mentoring and incident support. But unstructured feedback ("What do you think of Alex?") invites bias.
Ask specific questions:
- "Tell me about a time they unblocked you."
- "How do they behave in design reviews?"
This maps feedback to observable behaviors - collaboration, ownership, and technical judgment - rather than personality.
6. Factor in the Context
No evaluation is fair if it ignores the difficulty setting.
The Context Variables:
- Team Type: Feature work vs. Platform.
- Legacy Debt: Greenfield vs. 10-year-old monolith.
- Risk Profile: "Move fast" vs. "Don't break payments."
A "slow" engineer in a high-risk environment might be making the right tradeoffs to avoid incidents. Remember: Performance is a coherent picture, not a single metric.
Closing Thoughts
You don't need to be a developer to evaluate engineers, but you do need a system. If you rely on gut feeling, you will be biased. If you rely on ticket counts, you will be gamed. When you combine results, activity, and feedback into a coherent picture, not a single metric, you build a review process that engineers can trust.
Do This Next: The Performance Assessment Checklist
Audit your next review cycle against these four items.