Productivity and software development… a tricky topic. Managers often underestimate the complexity of the development process and want to introduce KPIs that appear to reflect productivity, but are actually pure vanity metrics – keyword “closed tickets“. As a team lead, you are then in a dilemma, because measuring performance indicators is a corporate reality and at least standard in big companies. It is therefore essential that software development also has to work with KPIs. KPIs enable optimisation and an evaluation of success, as long as they are well selected and interpreted.
This article is therefore about productivity tools at a business, team lead and individual level that should help to visualise productivity with various key figures and improve performance and workflows.
But first, let’s start with the “why”. Because it is often not clear what should be measured in the first place and who benefits from this measurement. It should also be clear to your developers why it is important to record certain key figures.
Then we present two tools for measuring productivity that provide indicators to improve processes and are interesting for you if you want to get an overview of the team’s performance and if it is your task to present KPIs per quarter.
You will also read about a list of tools that can be integrated into the development process and have a direct (positive) impact on the workflow.
Finally, you will receive an overview of an extremely underestimated tool: The survey.
Let’s start!
Start with the “Why”
When it comes to productivity, the push to think about a tool etc probably doesn’t come from your developers, but is
- a requirement from management.
- an opportunity you have identified to improve the development process or to clearly visualise KPIs
The goal is to have an overview of performance indicators that lead to insights to make better decisions and ultimately lead to higher productivity. You should therefore first ask yourself (and management) about which processes you want to collect data and how this could have a positive (higher productivity) impact…and if there is a negative impact.
In addition, you need to be aware that your developers are unlikely to be very fond of collecting data about their work. That’s why it’s important to communicate transparently with your team and present a real benefit in the best possible way. For example, if you think that your developers have too little time for coding and are constantly interrupted by meetings and context switches, you could suggest introducing time tracking and using data to convince your manager to introduce focus time.
Last but not least, it is also important to consider how the tool can be introduced – does this need to be clarified with the legal team? Who else is involved?
Summarised:
- What data do you need?
- What do you want to achieve?
- Which impact has the implementation of tracking tools?
- What are the benefits for your developers?
- Clarification necessary with which departments?
Developer Productivity Tools
You’ve probably googled “productivity tools for developers” or similar. You’ve probably come across numerous posts that randomly list tools. This is useful to get an overview. I think it makes more sense to divide tools into two categories:
- Do you want to track productivity and haveKPIs at your fingertips? (Tracking of key figures)
- Do you want to improve productivity directly with tools? (Improve workflow)
Let’s start with the presentation of tools in category #1.
#1 Developer productivity: Tools for tracking key figures
LinearB
LinearB is a tool for obtaining key performance indicators. LinearB allows you to visualise different data in a single platform.
LinearB is based on three core themes: Developer Experience, Engineering Tempo and Business Alignment. What does that mean?
- Developer Experience: We have already described the term in our glossary article: “The term ‘Developer Experience’ (DevX, DevEx) describes the environment, processes and culture in which software development takes place.” In other words: How smoothly does software development take place?
- Development speed: This is about a performance overview, monitoring key figures and how bottlenecks can be eliminated.
- Business Alignment: Optimising performance only makes sense if it goes in the right direction. It is therefore important to know what time is being spent on and where and how resources are generally being utilised.
For each metric, LinearB provides industry standards and benchmarks based on data from the company’s own customers. This benchmarking helps you evaluate your team.
LinearB offers a free tier. The use of DORA metrics is included. DORA is an established standard for measuring performance.e.
Jellyfish
Jellyfish‘s slogan is: “Anticipate. Build. Deliver. Ensure alignment throughout the entire engineering organisation to anticipate the future, build with efficiency, and deliver business impact.“
Jellyfish collects data from Git repos and Jira and combines it with individual calendars and roadmaps, for example. This creates an overall picture of how the team “works”. The data is also categorised.
So-called engineering signals are used to find out what teams are working on. These can be things like commits and pull requests for Git repositories.
Unlike LinearB, Jellyfish does not offer a free trial version.
#2 Developer productivity: tools to improve the workflow
Then there are tools that are directly integrated into the software development process and are intended to improve it. I have decided not to create an extensive list here, but to describe tool categories briefly and concisely. (Detailed lists and descriptions can be found here https://marker.io/blog/developer-productivity-tools or here https://www.getport.io/blog/developer-productivity-tools)
- Ticketing
- Project management; creation, monitoring and processing of tasks.
- IDE
- Programme for writing code efficiently. Find out more: IDE
- CDEs
- Remote development environments that can be deployed immediately and contain all the tools developers need to work. Find out more: Cloud development environments
- Version control system
- Track and manage changes to source code.
- CI/CD
- Automation to quickly transfer code changes to production.
- Documentation
- Description of the software.
And here are some tools that developers have described to us in interviews as “cool” 😉
- Infrastructure as a “playground” for developers: Server hardware that is available to developers, on which, for example, an internal Kubernetes cluster runs or on which developers can deploy VMs themselves. To my surprise, there was often a discussion of actual physical infrastructure, i.e. servers set up in the office or similar. The reason: Cloud infrastructure brings something with it – a constant discussion about costs. On the other hand, one-off costs for the purchase of hardware are often easier for developers to realise. Although the internal costs for maintaining and operating in-house hardware are significant, they are not tracked as a cost item and management is therefore often unaware of them – in contrast to monthly cloud bills.
- IntelliJ: The popular Java IDE from JetBrains has repeatedly been cited as a “favourite tool” by developers that makes their work easier.
- Auth0: I’ve heard raves about user authentication as-a-service because it solves all the problems of user invites, multi-tenancy, integration with single sign-on providers and user management itself so that the team no longer has to worry about it.
- Github Copilot was mentioned to me by a team lead as a valuable tool for code reviews, as Copilot helps him to quickly find his way around code that he has not written himself. Copilot was also mentioned as a valuable tool when it comes to working in a programming language that you haven’t used for a while.
- Datadog: A database with comprehensive observability features that are complex to set up, but then make working with large amounts of data much easier. Especially when many developers in the team have little experience with optimising database queries and simply don’t know whether the code they are writing is placing an excessive load on the database and leading to poor performance. If configured correctly, Datadog can make exactly this visible and thus become a very valuable tool that developers can use to learn how to write database-optimised code.
- Github Actions for monitoring and notifications: Being notified directly in Slack whether a build has failed or been successful helps developers enormously to react quickly – and to notice first – if their changes lead to errors in the build or deployment.
- Gitlab: Keeping track of code reviews, integrating directly with the CI pipeline and also having an issue tracker in the same place is very valuable for some teams and makes work faster than working with many different tools.
- Typescript: Helpful for front-end developers as it runs in the background and helps to find errors quickly.
- Self-built CI/CD pipelines, especially if there is a frontend that allows developers to see the status of deployments themselves. The fact that many companies have already built something like this themselves, and that it is perceived as very valuable by developers, clearly shows that the current trend towards “developer portals” and platform engineering is hitting a nerve.
- Renovate Bot: A tool that takes care of dependencies of pull requests. A test build is carried out to check whether everything works and if so, bug fixes and minor releases are automatically merged into the master branch.
- Snyk: A tool that automatically checks containers for vulnerabilities and relieves developers of a lot of research work.
- With a wink, the browser and Google were also mentioned to me as important tools in the development process 🙂
By the way, our CEO has shared her thoughts on 7 methods for increasing productivity – without any tools.
Bonus: Send out a productivity survey
Another cost-effective tool for gaining an insight into the daily work of your team and to increase productivity / eliminating blockers is to conduct a survey. In addition to tracking KPIs and using tools that support development, a survey offers a good opportunity to regularly ask about problems / obstacles, to receive individual feedback and gradually ensure a better developer experience. While you won’t get real-time metrics, for many organisations, a regular survey is a first step in enabling teams to become more productive.
What should you bear in mind when sending out a survey?
What needs to be considered? Will Larson, currently CTO of Carta, provides a good overview. His recommendations (summarised):
- Do not send out surveys if the problems identified in a previous survey have not yet been addressed.
- A maximum of one quarterly mailing, depending on the size of the company. For large companies: Interview some of the developers every week.
- Test the questions beforehand and rework them if necessary.
- Focus on qualitative rather than quantitative questions. Why? Quote: “It’s easy to fall in love with the quantitative aspects of surveys, but generally speaking I’ve not found the scores to be particularly useful. Internal surveys are often filled out by so few folks that changes are not statistically significant. Folks often get bored of filling out surveys so numbers can reflect who participates more than general sentiment. ”
His ideas on which questions are suitable (extract; unfortunately he does not provide a template):
- How would you rate our X process from 1 to 10? Where X is every common workflow at the company: test, code review, build, deploy, release, feature flagging, running experiments, reverting, incident management, on-call, debugging, and so on.
- What tools that you’ve previously used do you find yourself missing?
- Where do you feel like you lose time every week?
- Are there tools or areas of our code that you avoid when possible?
Our tips & template for a developer productivity survey
Here are two more tips for a successful survey:
- Communicate before sending out that a survey is being sent out.
Joking aside, there is a valuable tip in the meme: it should be possible to submit an anonymous answer 😉
Joking aside, there is a valuable tip in the meme: it should be possible to submit an anonymous answer 😉Questions we would send out:
- How satisfied are you currently with our processes in the dev team? (1-5)
- A question about satisfaction with the implemented workflows. An indicator of how the work and the whole “system” is perceived overall. It’s a “simple” introductory question.
- What are the biggest obstacles that slow you down or hinder your work?
- General question about blockers.
- Are there specific hardware or software problems that occur regularly?
- Specific question about obstacles.
- Do you feel productive? (1-5)
- A question about the perceived productivity and a measurement of individual satisfaction. Can be categorised in the last area of the DevX framework (flow state).
How can you send out these questions? For example, we use Typeform for surveys on our website to show which CDE best meets individual requirements. Typeform offers visually appealing templates straight away and can be highly customised. However, there are limitations in the free version, the number of responses is predetermined.
We use Google Forms for other surveys. Goolge Forms is a simple survey tool that can be used quickly and without limitations.
Let’s summarise:
- Create a survey.
- Get feedback.
- Adapt the survey if necessary.
- Communicate that a survey is being sent out.
- Send it out (all; subset).
Once the survey has been completed, it is time to analyse it. For multiple-choice questions, simply calculate an average and present it. Analysing qualitative questions (text answers) is more time-consuming. You can either analyse the data manually and categorise answers with codes (e.g. answer: “In my daily work, meetings are an extreme blocker.”). Categorisation: “Meetings”), or you can use LLM tools such as ChatGPT to quickly analyse the responses.
What to do after the analysis? Make the results publicly available after processing (if possible). This shows a genuine interest in improving your processes and serves as an incentive to continue participating in the survey.
Summary
- Before you introduce productivity tools to improve the workflow of your team or track KPIs, ask “why”
- Productivity tools for tracking KPIs:
- Linearb
- Jellyfish
- There are a huge number of productivity tools for improving everyday workflows. We have presented some of them in the text.
- Send out a survey to ask about blockers. Do this regularly to track progress.
