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:
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.
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.
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
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.
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.
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:
So here’s how our current process looks like:
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.
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 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% people who communicated proactively in public chats, but in June it was 90%:
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:
I will be glad to hear about your experience building similar processes in your company.
For managers and business owners who want to join us for the ride and are curious to implement a form of this into their organization, feel free to shoot me a line at firstname.lastname@example.org
Check out our newsletter