Developers’ productivity is essential to every business organization, big or small.
Nowadays, every company is in part a software company. As such, you’ll want to ensure that your developers are productive and performing to the best of their abilities.
This article aims to help you out, walking you through the six most common productivity killers.
Avoid the list below, follow our advice, and you’ll be well on your way to a productive developer team.
Table of Contents
Meetings and discussions
Coding is deep work, individual and immersive. If there’s a meeting at 10 am, developers are unlikely to write high-quality code that morning, as they know they’ll be interrupted.
Now imagine if there was another meeting at 2 pm, after the lunch break at noon—developers could never get their flow back.
In fact, the graph below shows exactly how much developers dislike meetings.
To sustain developers’ much-needed focus, it’s recommended to schedule all meetings for a single dedicated weekday.
That way, most of the week allows for the concentrated, constant deep work developers crave.
Bug and crash reporting tool for your mobile app.
On meeting day, however, it’s essential to know the meeting’s goal, namely, what questions you’re answering. Once that’s established, you can also determine who has these answers.
You can always brief the others afterward. They’ll probably thank you for it.
Besides meetings, instant messaging and email notifications are also terrible productivity killers.
It takes almost half an hour for someone to regain their focus after an interruption, and now, in the digital age, those lurk everywhere.
To prevent this, instruct your employees to simply turn off their notifications when they’re handling an important task.
You’re not leading a team of surgeons—no one is going to die without an immediate response.
Another tactic is not to check emails in the morning. By attending to emails first, everyone else’s needs distract developers from their daily tasks.
However, if they postpone reading their emails to, say, after lunch, your team members will have a much better opportunity to focus in the morning.
Try introducing this method as a regular practice with your team—it should dramatically increase productivity.
There’s not enough time for elegant code, so they leave things unfinished and adopt an I’ll fix it later mindset.
The consequences of patchy code are clearly numerous and derail developers’ productivity later on.
However, the biggest issue with technical debt is that non-technical stakeholders often don’t realize how damaging it is until it’s too late.
The damage only becomes apparent when new features are added to the fragile foundations.
Therefore, when justifying the extra refactoring to stakeholders, use business terms.
Explain that you want to reduce your TTM (Time-To-Market) or that too much budget was spent fixing quality issues.
That timeframe can be used to evaluate the architecture, prepare the groundwork for new features, and debug the code.
Your developers will appreciate it, as their jobs will be easier in the long run.
Maarten Dalmijin explains the perils of technical debt below.
Shake helps report bugs in mobile apps: users can send a detailed bug report to the development team simply by shaking the mobile phone. An example is shown below.
Users can include screen recordings, screenshots, and markup notes in the report—everything that should assist with the debugging and ensure you keep a clean code.
Non-technical managers making technical decisions
Non-technical managers making technical decisions is a conundrum. You’d think most would realize the futility of such an arrangement, but that’s sadly not the case.
Technical knowledge is a must when managing software development. Otherwise, managers lack the necessary expertise to make informed choices and don’t even realize it.
So, what exactly happens when non-technical managers make technical decisions? A real-life example is described in the post below.
In this user’s case, developers are so fed up with unproductive decisions that they’re even considering leaving the company.
Investing just a week of training would make a significant difference; managers would understand what they’re selling beyond the sales brochure and therefore become better at managing its progress.
There are even courses specifically designed for non-technical managers to gain technical awareness.
There are countless other programs, such as this one, readily available for anyone with an Internet connection and a bank account.
Inevitably, fresh technologies will surface, and managers won’t have time to keep up. Who knows, it could even happen to you.
Instead, own up that you’re not 100% on board with the latest and greatest.
Your team can guide you through the process and give pointers on what’s feasible and what isn’t. Hopefully, this is an approach non-technical managers are also open to adopting.
Other programmers hindering progress
Sometimes, the programmers are also to blame for low productivity, not just managers.
Something as banal as bracket placement can slow down the entire project.
This type of disagreement can genuinely happen on a development team, stopping the project in its tracks just because one employee won’t back down.
These types are the opposite of proactive and demand special attention as to actually work.
The problem with such programmers is that they create extra work for others. If one employee isn’t pulling his weight, the other team members have to clean up after them.
A Reddit user recounts his own experience:
Damage control usually falls to the other team members, forced to fix the mistakes of pedantic and disinterested developers.
If this situation continues for too long, your productive team members will resent not only their uncooperative colleague but also their passive team lead.
Carl Larson and Dr. Frank Lafosto have highlighted this.
It’s imperative to watch for unproductive employees and solve the problem before the morale (and productivity) of the entire team collapses.
Approach these programmers and explain the necessities of teamwork and how much their collaboration is valued and expected. Hopefully, they’ll correct their behavior.
When you examine these bad code statistics, the cost of letting one bad developer go seems minuscule.
If they don’t show any signs of improvement, sometimes it’s best to bite the bullet—it’s for the greater good.
Poor documentation isn’t the most apparent productivity killer, but it can be fatal.
Without documentation, however, you’re basically looking at the code through a layer of smog.
Imagine you’ve taken over a new project, and the documentation is the second type—two pages long, with the code six months old.
You’d quickly appreciate the benefits of quality documentation.
Unfortunately, developers tend to realize the importance of good documentation only after they need it.
Prevent this from happening to your team, and implement comprehensive documentation practices from the outset. Perhaps the easiest way is to focus on comments first.
Comments are an invaluable resource, as they explain ‘why’ the code is doing what it’s doing (the ‘how’ should be self-explanatory).
Look at this uncommented code:
It’s legible, but why it’s doing whatever it’s doing is a mystery. Here’s the same piece of code, but with comments:
With comments, we know exactly what this code was designed to do, and why.
Show the difference to your team—they’re bound to notice the benefits and should begin including regular comments.
A README document provides a general overview of the software, highlighting the most salient points. It often also has guidelines on how to install and run the software.
Everything under the sun is covered, and you can tell right away if it’s relevant to you immediately.
It’s worth introducing your team to its benefits and educating them on how to write a good README.
Small changes can make a world of difference.
Coding is a highly technical, particular process, and inadequate tools can make or break the quality of someone’s output.
Having such a comprehensive workstation is his way of doing things and allows him to code to his best ability. You’d be slowing him down if you take away even one component.
What is more valuable—your employees’ long-term working speed or a couple of hundred dollars of short-term expenses?
When a developer requests different or upgraded tools, speak to your finance department. Ask if the expense is within the budget, and explain the developer’s contributions to the company. Strive to illustrate their worth, and even put it into numbers if you can. Do what you can to equip your team with the best equipment out there—it should pay off in the long run.
That way, you save your team members time since they won’t have to toggle between emails, windows, and apps. The investment pays off when you realize how many minutes you’re saving.
Such statistics are a great incentive to opt for a single, one-stop software. Such a tool is bound to increase your developers’ productivity.
If you recognize any of the above at your workplace, take action.
If technical debt and poor documentation are eating up your developer’s hours, implement regular refactoring and technical writing hours.
Alternatively, if programmers or non-technical managers are causing friction, single them out, sit down with them, and try to work through the problems.
Finally, if inadequate tools impede the progress of your team, speak to the finance department about implementing new equipment.
If meetings constantly interrupt your employees, condense meetings to one dedicated day.
We hope the above advice makes a difference. Follow it, and your team’s productivity should shoot through the roof.