"The code runs" is the floor, not the bar. Real engineering maturity is about how someone handles scope, ambiguity, and people, not just whether their feature works. The simplest definition I use: an engineer is growing when they can take on bigger problems with less guidance.
| Signal | Less mature | More mature |
|---|---|---|
| Problem size | Needs well-defined tasks | Takes on open-ended problems |
| Guidance | Needs steering | Operates independently |
| "Done" | Code merges | Outcome delivered and owned |
| Blast radius | Their own work | The team's effectiveness |
Two engineers both ship a feature. One closes the ticket. The other flags a risky edge case to the PM, adds monitoring, and writes a short doc so the next person isn't lost. Same code shipped, very different maturity, and it's the second behavior I'm promoting toward.
If you only measure whether code works, you reward output and miss the things that actually compound: judgment, ownership, and lifting others. Naming these criteria explicitly gives engineers a clear map of what "growth" means, and gives you a fair, consistent basis for feedback and promotion.