How do I know my technical team is performing well? — answered by Engineer Saeed Baatiah
Do not measure by hours worked or by volume of code written — both mislead. Ask four questions instead: how many times did something working reach users this month? How often did something break after delivery? How long does fixing a failure take when one happens? And could someone else continue the work if whoever built it were away? That fourth is the most dangerous and the least asked.
Why hours and code volume mislead: a lot of code may mean a complex solution to a simple problem, and long hours may mean poor planning rather than dedication. Both metrics reward activity rather than outcome, and once a team knows it is measured by them it produces more of them — the worst thing that can happen to the quality of your work.
And the fourth question — “could someone else continue?” — is the most dangerous because it measures risk rather than performance. A team producing fast where everything depends on one person looks excellent until that person falls ill or resigns. Test it practically without confrontation: ask someone else to take a small task in a system they did not build, and see how long it takes and what they need.
And a management indicator needing no technical understanding: do estimates reach you and mostly hold, or does everything always slip? Constant slippage is not necessarily laziness — it may mean nobody says “no” to new requests, or that estimates are made under pressure to agree. And the fix is managerial rather than technical: ask what was removed from scope against what was added.
- Do not measure hours or code volume — they reward activity, not outcome
- The most dangerous: could someone else continue if they were away?
- Test it: assign someone a task in a system they did not build
- Always slipping? Ask what was cut from scope against what was added