Evaluating Engineers: A Three-Step Guide

Problem

One of the first tasks I encountered in my new role was to decide who would stay on the team. Most developers were freelancers, and finding people who could contribute to a company of our size and growth rate was not an easy task. As a small company, we still hadn’t invested much in processes that would help me make that decision. We didn’t have performance reviews and a formalized career ladder, and our productivity tracking was fairly rudimentary. I came up with a simple three-step guide that served as a foundation for our prospective evaluation process. It consists of performance assessment, career path conversations, and productivity measurement.

Actions taken

Assessing performance

The key to assessing performance is to understand what the company needs and how it operates. We don’t use Scrum, don’t have sprints, and are not time-bound. We would have a general agreement that some features need to be shipped at some point within the quarter. That gives me the flexibility to allocate work to a particular engineer or a group of engineers. Our main tasks for each quarter are prioritized and fall under some of the initiatives that should be delivered within a certain increment of time, but typically there is no strong ‘estimated time of delivery.’ This approach significantly reduces stress, frees time for the “maker’s schedule“, and allows people to be more creative and solve problems without haste.

I assess my engineers’ performance by evaluating their technical competence and their interaction with their team members and the business.

• Technical assessment

I set the bar for what the company’s expectations are in terms of the quality that has to be delivered. Engineers will be introduced to our quality standards during the interview and then be able to learn more and further improve their skills. Our tech lead, who is technically the most competent person in the company, reviews the code, and makes sure that we follow the highest industry standards. A technical skill I find essential is the ability to solve problems.

• Soft skills assessment

I find soft skills critically important in small teams where engineers cover different areas, and their skills go beyond what should strictly fall under the typical engineering job. I pay particular attention to how they interact with other fellow engineers and non-technical staff, but also how they communicate problems, do status reports, document their work, etc. I highly value communication skills, providing constructive feedback, curiosity, and being an eager learner.

Career path conversations

One of the first conversations I would have with my engineers would be about their prospective careers. I am mostly interested if they are willing to pursue a technical or management path. Currently, we are a too-small team to provide management opportunities, but they could work on improving their management skills and become more familiar with the business side of the organization.

We would regularly talk about their plans for the upcoming quarter or year -- what are the things they want to learn or experience --, and I would try to support them in their aspirations. I would provide them with literature, coaching sessions, create opportunities, or support them in any other way. If that includes leaving the company in pursuit of their professional development, I will empower them if I think that it would help their growth.

We are still too small to introduce levels, and I would prefer us to stay horizontal as long as possible. In my opinion, flat organizations allow people to grow as they impel them to work in multiple areas. In a short period of time, they could acquire a broader experience than if they would be more specialized. Flat structures also empower people to roll up their sleeves and do whatever it takes -- whether it falls under their job description or not -- to complete a task. However, if they want to specialize more, they don’t need to be placed in a separate team; we as a company can help them by arranging for courses or additional education in those areas.

Measuring productivity

I would measure productivity of my engineers by following their work closely but without being obsessed with metrics like a number of tickets or lines of code they completed. We are using Kanban and trying not to put time pressure on our engineers. It is crucial that we, as a team, could ship a feature or fix a bug without having to do it multiple times because we are rushing to deploy it. I adhere to the principle -- Do it right, no matter how much time it will take.

We have a project management system that allows me to track how many features or bug fixes every single engineer completes daily, weekly, and quarterly, but we only use those as milestones. While we don’t have strict working hours, engineers are expected to be available during the working hours as agreed upon.

Lessons learned

• Without the pressure of being time-bound, people are empowered to choose tasks that can unlock their potential and boost their productivity. They are free to take as much time to achieve excellence. Whenever they need days off or have difficulties focusing, they are welcome to communicate that to me, and I will be happy to meet their needs.
• Document any performance-related activity and make sure that management at any given time has all information needed. While it is often time-consuming, keeping track of the team’s performance is essential for driving transparency and fairness across the company.
• Have regular, weekly one-on-ones. That will allow you to connect with another human being that is ‘hidden’ behind a role. Often we unintentionally reduce people to their roles, failing to understand why someone is less productive or has a hard time focusing. Be a manager who is empathic, unafraid to show their vulnerability, and stands for their team.