Giving quality feedback to employees

Sharing is caring!

About 5 years ago I had been working for a large software development company and I was leading three other developers on one of their main initiatives. I was extremely ambitious and seeking professional growth and guidance from managers and senior engineers alike. Yet despite my efforts, my largest hurdle was that nobody was communicating ways for me to improve in my role and I wasn’t receiving feedback on my work.

For such a large company, I was perplexed. One day, I requested feedback from my manager. My company assigned a senior engineer to review the project I had been assigned and the source code in order to report with some feedback. On the next day, I received a half-page email summarizing the review of my work. After reading through their feedback, I came to a few realizations:

• Time was not taken to review my work: The senior engineer suggested for me to use other frameworks and tools, yet neglected to spot that I had suggested the same technology stack in the beginning, only to assess that it would not work out due to a high load. In the end, I opted for another solution.
• Generic advice and recommendations were used: The bulk of the feedback contained generic advice that could be found on the first page of a Google search.
• Lack of personalization: There were little-to-no personal recommendations provided to me.
• Impersonal feedback: To make things worse, I didn’t know the senior engineer as he did not work on my project.

It was clear to me that less than an hour’s worth of time was spent evaluating over a year’s worth of my work. At that moment, I debated investing my time in a company that didn’t invest in me and considered building my own company.

Feedback Matters

Fast forward five years, it’s never been clearer to me that employees are the most valuable asset a business can have. This couldn’t be truer for a software development company – we don’t own real estate nor expensive equipment; everything we have is in our intellectual property and the time of our team.

I figured out that my experience was not far off from other developers in the industry. Amongst the perks of a job, such as a decent salary, benefits, and other bonuses, it is professional growth that matters most to people. Companies attempt to provide growth using different approaches, but the one foundational concept central to all these approaches is the need to provide quality feedback.

Ingraining Feedback Culture into Process

As a team of engineers, we have clearly established processes for software development and communication, so would we treat feedback any differently? We were convinced that it would benefit from a process as well.

Initially, we had to resolve the following challenges:

• Feedback should be objective. It won’t work if feedback is heavily swayed by someone’s mood or impression.
• Feedback should be provided regularly. No matter what happens, it is proper hygiene to always allocate attention and time to your employees. Acting otherwise leaves employees feeling neglected and disengaged.
• Feedback should be delivered by the right people. Of course, any and all feedback is welcomed, but effective feedback should be delivered by a person having enough authority and experience so that the employees know that it is qualified.
• Feedback should drive positive change. Therefore, there is an opportunity to track what feedback is provided and when, and whether positive changes stemmed from it. We learned that it doesn’t matter how skilled your employee is: the only thing that matters is if a team member can absorb the feedback they are given and learn from it.

It wasn’t possible to keep everything in mind or rely on that. Not to mention, there were three of us (co-founders) who managed teams and projects in the beginning and we needed to synchronize with each other. Naturally, we started making records and then formalized that process. Every week the three of us used to allocate 30 minutes in order to put together notes and discuss them. After a few months, our notes-making process transformed into performance metrics collection.

Performance Metrics We Track

Below are some of the metrics we collect for everyone on the team:

There is something very important hidden behind every metric we track. We have a detailed explanation for every line with examples so that we deeply understand what it means. For example, we have a playbook describing our processes and it serves as a single source of truth for everyone on the team when it comes to our processes.

Can you see the last metric (WLD) on the screenshot? We’ve taken the win-loss-or-draw concept from one of the projects we’ve been working on. It works in a pretty basic way: we evaluate a week of every teammate as a WIN (went above expectations) DRAW (good, nothing extraordinary) or LOSS (something went wrong). It is the most subjective metric we track, but it helps us to record our thoughts on progress and momentum in a way that we can use to synchronize expectations with the team.

Of course, different teams can track different types of data. It would vary across your company culture, values, priorities, and experience. We have changed our metrics several times to track data that at a first glance might not seem important. For example, we have a metric called “No working time anomalies”. A few years ago we discovered that overtime didn’t lead to optimal results for us.

If a team member had worked for more than 40 hours a week, 8 hours a day or on the weekend, it always led to undesired consequences.

People lost motivation, which was reflected in their mood and ultimately it spiraled down to the team our ability to overachieve on projects. After we eliminated overtime, we noticed a positive change across the company and since then, we’ve kept tracking this metric. This worked even better when we started working remotely.

Introducing Self-Metrics

We had this system in place for some time but eventually, we hit a new challenge: as people who collect metrics and provide feedback, we realized that we were not getting feedback for our own work. The issue became larger when our team grew, and we formally introduced new management roles of Lead Developer & Project Manager and asked them to fill in the metrics on their teams, yet there was still no one who could provide feedback for them. I attempted to collect that feedback from clients, but they could not track any data for us (or rather, it wasn’t really client-friendly for me to ask them to do that). At the same time, my co-founders and I could not participate in all of the projects as we had to track the data on our own.

One day, we decided to introduce self-metrics.

The idea is fairly simple: you don’t need someone to track data on your work, you can put it yourself and get valuable insights from your teammates. It took us a few weeks to prepare our first draft. When creating this draft we were thinking about our past mistakes.

What issues did we have? How could we prevent them? How could we know if something wrong was going on?

The result is below:

These performance metrics represent some kind of knowledge base. If someone puts a “-” they could immediately see the follow-up questions to understand the reason and ways of how they can fix it:

How We Collect Performance Metrics

So here’s how our current process looks like:

• Every Monday morning our lead developers and project managers allocate 30 mins to fill in the metrics on their team as well as their self-metrics
• After that, we (co-founders, lead developers, and project managers) have a 30-minutes call to go through the self-metrics and discuss if we see any issues or tensions
• Then we allocate 30 more minutes to go through the metrics of everyone on the team to see if there are any issues or our attention is required
• One or two times a month our project managers and lead developers (or we on our own) schedule 1-on-1 meetings to share our feedback based on the metrics we collected

Think it’s too much? I was worried about that too when we first started, but the results have been overwhelmingly positive. It all led me back to the realization that started us down this path: People want to grow, and they are waiting to be engaged. As a manager, it’s also a good feeling to understand what is going on in your company and how everyone on the team is doing.

If you are interested in building company processes read how we organized transparent development and communication processes in the company.

Metrics Tracking Benefits

While the initial idea was only about providing feedback, it ended up growing into something much more beneficial. Based on the metrics, we can now make sound decisions such as:

• When it is time for a salary raise
• When it is time for a 1-on-1 meeting
• Whether a teammate has any personal problems and requires some additional attention from us
• And many more…

When we provide feedback we make notes that help us to understand who provided which feedback and monitor how a person reacts to that feedback.

As one more benefit, it is possible to process the data we collect and analyze it. For example, after we introduced a metric about proactive communication in teams, we observed a dramatic increase after 3 months. In March there only was 40% of people communicated proactively in public chats, but in June it was 90%:

What’s Next?

Using Google spreadsheets is a painful way to run our feedback and data tracking process. We are looking for a solution that would help us doing pretty much the same but also:

• Set up permission levels to access the metrics
• Analyze the data we collect automatically
• Set up reminders in case if somebody forgot to fill in the metrics
• Give some insights and recommendations (for example, if a person has 3 Losses in a row suggest to set up a 1-on-1 meeting)

I will be glad to hear about your experience building similar processes in your company.

• How do you provide feedback to your employees/teammates?
• Do you have a process for that?
• How do you understand if your team is doing a good job?
• Have you ever tried to collect any metrics? What data do you track?

About the author:

I have passed a long way from Software Engineer to CEO of own software development company. During the last 6 years, I’ve participated in 20+ IT projects and gained experience in a variety of business domains such as entertainment, social media, ridesharing, advertising, banking, real estate, and many more.

I know how to build successful IT products & companies and share my knowledge with our clients at datarockets.