MEASURING PERFORMANCE FOR TECHNICAL TEAMS
Recurring question when talking about a tech team; “Is your team efficient?” I literally spent months in this question, trying to solve the unsolvable. After all, a short answer, I have no idea. Hard to know, and in fact, we don’t care. The question should be; “Are your processes efficient?”.
There is a big difference between measuring a team's performance and measuring a production system's performance. Developers are artists; they write code as a writer to write books. Except that a book ends at some point, while code is infinite. Trying to measure the productivity of an artist is pointless. You hired these folks; you trust them because you tested them already. If some got demotivated, there is human behavior you can catch to sort this situation. On the other hand, it is essential to understand that a group of very talented individuals could be terrible in execution all together. What makes the team successful are the processes, which is when we talk about performance. What are the processes that make your team successful?
BUILD A FRAMEWORK
“Alone, we go faster; together, we go further.” The problem with together is that working as a group requires alignment, sharing knowledge, discussing decisions… It is a lot of new issues you didn’t have before. It is up to you to find what makes your team more productive, constantly oscillating between chaos and bureaucracy.
Agile is a buzz word.
Gracefully, the industry had come with a lot of concepts already discussed and well established by smart guys before you even had to think about it. Go over the internet and ask about agility, sprints, kanbans… Great knowledge is available online but definitely not plug and play.
First, because many articles are written with the idea that it just works, people who write articles usually want to sell something, like how simple it is to earn money over the internet (classical). More importantly, each company has its own environment and constraints. What makes Facebook successful is not what's going to make yours a billion-dollar company. You have your own issues; you should have your own solutions.
This being said, you don’t want to reinvent the wheel. A good starting point is a weekly retrospective; that is, to me, the only thing you should implement at first. Do not fall twice into the same trap. Gather your team to discuss problems, then, over time, think about solutions. The true meaning of agility is the ability to adapt to your environment. Change your concepts and habits as fast as possible to fix issues as they are coming to you, not before. Agility means being agile, not doing poker planning, neither hiring a scrum master.
Focus on simplicity.
When building your framework, always think about simplicity. Don’t over-engineer solutions; you will need simplicity to pitch these solutions to your team and make them used by everyone daily. Sharing knowledge through a team is a challenge. If your organization needs documentation, then it is too complex. It must be easy to understand, one can pitch the others, and it just makes sense. Obvious solutions to obvious problems, that’s it!
The complex methodology needs more rules to work, and rules need to be enforced. That is the base of rules; they are boundaries that avoid inappropriate actions. An unrespected rule is useless, creates friction and frustration. The more you create rules, the more you have a chance to break them, the more you have to enforce them, the more it creates frustration. In other words, you don’t want to create too many rules.
Leverage software instead of written rules. Every basic rule can be enforced by tools like a linter for coding style, for instance. Git comes with a very well-made framework around; Reviews, approvals, protected branches…. This way, you can rely on a neutral system that is self explainable—everything you need to build a decent, simple framework, easy to comply with, and efficient by design.
MONITOR YOUR PROCESSES
Depending on your business, your priorities would not be the same. What’s your main concern for your business? Despite your objectives, assessing a production framework is often oriented around time!
Understand what time means.
“Time is money” because a company consumes money while running. Therefore, time is fuel, and it can be consumed in many different ways. Breakeven companies and startups have different approaches, considering how to consume time. This being said, measuring time without taking the company strategy into account is pointless. Being efficient is not about consuming less time; it is about consuming the right amount for the right task.
There is no secret sauce about this point; the only advice I can give one is, think about it carefully, how do you want to invest your time? If quality is a must-have, you will invest in code reviews, tests, and any other step you might consider improving quality. At Comet, we do code reviews during the development process. How much does it cost? How long does it take to pass the review? Code reviews negatively impact the time but positively impact quality.
You only need feedback.
We measure our workflow using the GitLab API. Because Gitlab is a central solution to our work environment, we can measure the time between ticket creation and its product delivery. Think about package delivery; it works the same way. Each feature, bug, or chore task has a Gitlab issue attached to it. Issues in GitLab is a good way to communicate specifications among team members plus; it allows the team to get traceability from its creation to its merge into production.
Using Gitlab CI allows you even to track the build, test, and deploy latency. This gives you the best feedback available to track where your team invests time. With this in mind, you can decide whether the return on investment is good or not.
At Comet, we developed a custom tool based on Gitlab API because we wanted to integrate quality metrics from third-parties like Sentry, Datadog, and other providers to link our productivity metrics with our OKRs.
THAT BEING SAID
Don’t lose too much time trying to solve unsolvable concepts, like calculating a development team's productivity. Simplify the issue you want to tackle and focus on what matters the most, your production methodology. Build your own, based on observation, communication, and leverage tools to give you accurate feedback about reality. Remember, as a company, your fuel is the time; it is as simple as answering the question; How do I consume time?
