KRAs that fit each IT role
Write KRAs around what each role actually controls. A developer owns delivery against sprint commitments and code quality. A QA engineer owns test coverage and the defects caught before release. A tech lead is judged on team delivery and mentoring, and a project manager on client satisfaction, margin and schedule. Keep four to six KRAs per role, give each a weight, and include one for learning, such as a cloud certification, because current skills are what get people allocated to good projects.
- Developer: sprint delivery, code review findings, production defects traced to own code
- QA engineer: test coverage, defects found before UAT, automation scripts added
- Tech lead: team velocity, design decisions documented, juniors mentored
- Project manager: client satisfaction score, schedule variance, project margin
Worked example: weighted progress for a developer
Sneha, a Java developer, has four goals for the year. Sprint delivery carries a weight of 40 and she is at 90 percent progress. Code quality carries 30 and she is at 80 percent. A cloud certification carries 20 and is done, so 100 percent. Knowledge sharing carries 10 and she is at 50 percent. Her weighted progress is 0.4 x 90 + 0.3 x 80 + 0.2 x 100 + 0.1 x 50, which is 36 + 24 + 20 + 5 = 85 percent. ZeniaHR shows this weighted progress per employee and rolls it into the cycle summary for HR.
When engineers move projects mid-cycle
In a services company people change projects often, and a review written only by the latest manager misses most of the year. The goals sit with the employee, not the project, so they survive the move. Before the move, ask the outgoing project manager for a short written note on delivery and quality, and keep it with the review papers. Update the reporting manager in ZeniaHR on the day of the move, so approvals and the next review go to the person who now sees the work.
Review rhythm and what ZeniaHR holds
Services firms often run an annual cycle from April to March with a mid-year check, while product companies tend to prefer quarterly OKRs. Create the cycle in ZeniaHR as annual, quarterly or ad hoc with your rating scale, and add goals typed as KRA, KPI or OKR, each with a weight. The appraisal conversation, self-assessment and calibration meetings happen in your usual format; ZeniaHR keeps the cycle, the weighted goals, progress and the cycle summary in one place for HR.
How to set it up in ZeniaHR
- Create a performance cycle, annual for services teams or quarterly for product teams, with your rating scale.
- Add four to six goals per engineer typed as KRA, KPI or OKR, each with a weight, so the weights add up to 100.
- Include a learning goal, such as a certification, for engineers expected to pick up a new skill this year.
- Update the reporting manager on the day of every project move so the right person handles the review.
- Use the cycle summary to check progress across teams before calibration meetings.
Read more about performance in ZeniaHR.
Roles this applies to
See performance and kras for it and software companies in a demo
We set up your locations, shifts and rules on a video call and show it running for your team. Free for your first 50 employees.
Book a free demoSee pricingFrequently asked questions
What are good KRAs for a software developer?
Typical KRAs are delivery against sprint commitments, code quality measured by review findings and production defects, contribution to design and documentation, learning new skills and teamwork. Each needs a measure and a weight. For a senior developer, add mentoring and technical decisions; for a fresher, give learning a higher weight in the first year.
How often do IT companies do performance appraisals?
Many run a yearly appraisal tied to the April increment, with a mid-year review in October. Product companies and startups often set goals quarterly instead. In ZeniaHR, cycles can be annual, quarterly, monthly, probation or ad hoc, so quarterly goals and a yearly rating can run side by side without two separate systems.
How do you review an employee who changed projects during the year?
Collect written input from every project manager the person worked with, and let the current manager combine it in the final review. Goals that belong to the person, such as certifications, carry across. Record the reporting manager change on the move date, so approvals and the review reach the manager who now oversees the work.