Back to resources

Evaluating Engineers: A Three-Step Guide

Productivity
Coaching / Training / Mentorship
Career Path

27 January, 2021

Daniel Lobo
Daniel Lobo

Engineering Manager at Curebase.com

Daniel Lobo, CTO at Explore-Share.com, explains how he evaluates engineers by following his three-step approach that includes assessing their performance, discussing the career path, and measuring engineering productivity.

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.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

Assessing the Performance of Your Team

20 August

Parallels between Work and Sport.

Goal Setting
Different Skillsets
Coaching / Training / Mentorship
Performance
Ron Pragides

Ron Pragides

SVP Engineering at Trustly Group AB

Leaving Room to Say Things Suck — Leadership Lessons from “Ted Lasso”

17 August

A major sign of trust, comfortability, and vulnerability is for someone you lead to be able to say something sucks.

Building A Team
Company Culture
Leadership
Coaching / Training / Mentorship
John Hartley

John Hartley

Senior Engineering Manager at Curology

How to Enter QA With a Non-Technical Degree

2 August

Lewis Prescott, QA Lead at Cera Care, explains his journey from a degree in psychology to learning test automation and computer programming.

Handling Promotion
Personal Growth
Coaching / Training / Mentorship
Career Path
Lewis Prescott

Lewis Prescott

QA Lead at CeraCare

How Product Management Chose Me

23 June

My accidental journey into product management

Product
Personal Growth
New PM
Career Path
Michael Castro

Michael Castro

Sr. Manager, Product Management at Capital One

How to Help Employees Find Their Strengths and Passions

22 June

Łukasz Biedrycki, VP of Engineering at BlockFi, talks about the importance of building on your strengths and finding your passions to maximize your impact. He dives into the tactics that managers can use to support their teammates in this pursuit.

Different Skillsets
Personal Growth
Leadership
Motivation
Career Path
Performance
Łukasz Biedrycki

Łukasz Biedrycki

Head of Engineering at Spectral Finance