In the last three years that I’ve managed performance evaluations of support engineers for an IT consulting firm, I’ve been wary of assuming a judgmental stance – either directly or through the feedback process I’ve helped manage. Performance reviews are known to be tedious exercises for all concerned so my objectives for them have been to seek and provide feedback, identify development goals and, at the end, ensure an inspired bunch.
The forms I’ve designed have meant to act as the firm’s listening tools extended to an employee’s varied stakeholders…to i) peers to know the colleague’s collegial quotient; ii) managers on behaviors exhibited and the level of support provided; iii) vendors on clarity of communication and extent of follow-up experienced; iv) any juniors on the candidate’s openness to develop them; and, importantly v) the employee on good and bad processes he experienced, the learning he’s had, and the goals he plans for the ensuing period.
The firm is small and proactively customizes its IT solutions to its clients’ business practices and goals—whether a profit-oriented company or a philanthropy extending support on health research, an engineer placed there has been encouraged to know the organization’s programs and become a part of their work culture. This has necessitated openness to adapting to a client team’s specific IT requirements as also remaining learners of new technologies so they do not stagnate in their careers as a result of narrowly defined roles. Engineers are continually advised to be self-starters but also follow a reporting mechanism that keeps their stakeholders in the loop on the day’s critical incidents. This requires an engineer to be appreciative of documenting and reporting, and yet working independently. The review process provides for frequent coaching discussions to help get young engineers close to these role expectations.
The Performance review framework is guided by the following philosophies:
360 degree feedback. The manager is only one of the stakeholders in a candidate’s performance. If he’s the only person heard, the feedback sought will be only of one kind—say, with a bias towards the service tickets opened and closed. His colleagues, juniors, outside customers interact with him more frequently and are impacted by his other competencies so would provide pertinent inputs on his overall performance.
Self-appraisal. Although considered unnecessary by some HR pros, I see it as a motivation tool. It provides a clear opportunity to an individual to summarize his achievements of the period, highlight the support he needs, and chart out a course for future learning.
Two-way communication. The process aims to seek and provide feedback to a candidate on his performance. For an engaged and productive employee, it’s critical for the firm to listen to his experience of working with his external and internal customers as also suggest any changes in processes.
Avoid a Recency Effect. The combination of 360 degree and self-feedback helps guard against any recent high or low performance events coloring the whole period’s output. Besides, for a team as small as this firm, it’s been possible to record critical incidents on a candidate’s performance and include them in successive review discussions.
Continual coaching and development. Instead of scheduling one-on-one coaching sessions only around a review discussion, an engineer is coached regularly—in person and by sharing links to podcasts or resources via email. Recently, when two engineers recorded their interest in learning the use of open source tools to secure networks, their manager had a former engineer conduct a workshop which he also attended and acted as the presenter’s resource. This was inspiring for engineers and hopefully gave them a better idea of the trajectory they would follow. Or, not follow.
Manager as a role model. A manager’s own method of analyzing a hardware or software glitch and going through a checklist of possible solutions is imbibed by his engineers. So are his other attitudinal traits so it’s been important for the senior manager to regularly–not daily though– visit the client sites and be aware of his influence.
Less control, more development. The emphasis has been on empowering engineers to act and take decisions while keeping all stakeholders in the know. I’m glad to see that a conventional method of management-by-walking-around or ensuring a head glued to a screen have found no place in the firm’s approach towards developing its engineers.
Benefits only a cog in the wheel of feedback. Where performance reviews are annual exercises, they’re closely tied in with a compulsory annual raise so treated more as a procedural compliance feature of one’s work life. Here, benefits are discussed as an annual event so they cease to appear continually into an employee’s periodic development discussions.
Keep it simple. It’d be tempting to make impressive 4-pagers as tools to seek feedback but they would also continue to daunt people to fill or analyze the inputs. In consultation with the lead manager, I tweak the checklist of essential areas of focus for the period, and develop a questionnaire to cover them. The attempt has also been to ask brief questions but hope for a detailed feedback.
Is there anything else I should be including in this framework? I’d be interested to know about your experience with performance reviews and whether you’re looking forward to your next review discussion 🙂
Jyoti's Musings 