Whether you are a developer yourself, or you manage or work with developers, here is a list of action items you can use to identify and address common time sinks and productivity blockers faced by many developers.
Feedback is welcome at margot@cloudomation.com
#1 Meetings
Many people dislike meetings. Developers might be particularly averse to sitting in on discussions that they feel do not concern them, or where they have nothing to contribute.
Ask yourself:
- Is it likely that the developer will speak during the meeting?
- If yes, is what she or he is likely to say going to be helpful and contribute positively to the purpose of the meeting?
- Is it possible to reach the purpose of the meeting without the developer present?
Developers should only be required to attend meetings for which the answers to these questions are yes – yes – no.
Purely informative meetings are not a thing. A meeting where a person is only required to attend so that she or he is aware of what is happening is not supposed to be a meeting. It should be covered in an email or a video or any other format that can be consumed asynchronously, and ideally in a way that fits the speed of the consuming person (i.e. can be cross-read, has a summary, can be sped up or slowed down …)
#2 Speaking with other people
It is a stereotype that developers don’t like speaking with people. I have found it to be accurate in a majority of cases. My recommendation extends to all developers, even those that do like speaking with people.
Here it is: Create spaces for developers to speak to people that they need to speak to.
A very common blocker for developers is that they don’t make progress on a task because they need something from someone else, and they are not getting it. More often than not, they did not ask for it.
A way to avoid this bottleneck is to create forums for developers where they get in touch with other people that they may have dependencies on – without the developer having to take the initiative. Daily standups are such a forum, where developers get in touch with other developers on their team. Weekly sync calls (5 minutes are enough) with their manager are another such forum. If your team has a lot of dependencies with another team, a regular joint status call might make sense.
Note that these regular forums should not grow into pointless meetings where a lot of people sit in and listen to the one junior developer asking a question. Individual discussions should be taken offline, and where possible, meetings should be optional, with only those attending that need something.
Another way to achieve this is already baked into the scrum format: Developers should talk about their blockers in the daily standup. A supportive manager should make sure that (a) developers actually mention their blockers and (b) support developers in resolving them, e.g. by setting up a meeting between the developer and someone else who has information they need.
#3 Admin
At least as frequently bemoaned as meetings, administrative tasks are a common time sink that some developers take to (much to) keenly, while others avoid them like the plague. For the first kind, administrative tasks really can become a significant time sink if the developer just happens to enjoy organising their backlog with coloured icons and a consistent tag-label-scheme. For the second kind, administrative tasks feel like a huge waste of time and can have a serious impact on their well-being and productivity even if the actual time they spend on it is small.
So: Minimise the number of administrative tasks developers have to do. It’s as simple as that.
Tips on doing that:
- Make task management as simple as possible, e.g. by tolerating a large, unkempt backlog. If a ticket is important, it will surface. Three levels of priority are sufficient. Any ticket that can be categorised as “not now” doesn’t need any more time or headspace wasted on it.
- Automate as much as possible. There are great apps that make expense reports really simple. There are great integration tools that can copy data between systems – and are much cheaper than your developers entering the same information in different systems several times.
- Make time tracking as simple as possible, e.g. by integrating time keeping with the ticketing or even source control system. Or switch to not tracking time and trusting developers to manage their time. You might get more out of it overall.
- If your developers do track their time, introduce an “admin” category they can track time on and see what happens. It might create an appropriate sense of urgency if developers suddenly track a quarter of their time on “admin”.
#4 Focus time
Not all meetings and administrative tasks can be avoided, and not all services can be automated, so developers will inevitably still spend time on tasks other than working on code. But even if the time spent on other activities can’t be reduced, structuring how developers spend their time can have large benefits for their productivity.
Many developers report frequent interruptions in their work as a major drag on productivity. Reducing interruptions and increasing the focus time available to developers is a real quick win when it comes to productivity hacks.
Introducing company-wide focus time – e.g. saying that no meetings should be scheduled and there is no expectation that slack messages or emails will be answered before 11 a.m. – will give developers the opportunity to get several hours of uninterrupted focus time each day.
Of course there are those developers who then will start their day only at 11 a.m. – but they can get their focus time later in the afternoon when everyone else has clocked off 🙂
#5 Avoid multitasking
One thing I have said many times and repeat whenever the stress level rises is: “Do one thing after another.” (“Eins nach dem anderen” in my native German.) It sounds a lot more simple than it is. It means finishing one thing before you start the next one.
Switching context is costly. Having to mentally switch from one task to another takes a toll. Doing so as a developer often has more than just mental cost: It can mean resetting the entire development environment, spinning up new environments, or other time consuming activities that have to be repeated every time a developer switches to a different task. Sticking with one task until it is done will, more often than not, significantly reduce the total time it takes to complete it. This is why it is paramount to stick to finishing things especially when there is too much to do and too little time.
In addition to saving time, finishing tasks reduces mental stress and provides a much-needed sense of progress especially at times when there are too many tasks on the todo list.
To enable this:
- Reduce dependence on others and waiting times in the completion cycle of a task. For example, reducing time to wait on automated tests to finish will reduce the likelihood the developer starts on a different task while waiting for the test results. Same for code reviews: the faster they are done, the more likely it is that the developer will still be in the mental headspace of the task when receiving feedback on it.
- Provide alternative tasks: If waiting times are inevitable, make sure that the developer has tasks they can work on that don’t require a lot of context switching, or can be done quickly – e.g. code reviews for colleagues, or writing documentation or unit tests for the feature they just worked on.
- Allow iterations. If a task only counts as complete when it is perfect then developers will never be able to complete it in one go. If the definition of done for a feature involves documentation, tests, and several other steps then this should be broken down into separate tasks that can be closed separately.
#6 Clarity
The more there is to do, the more important it is to prioritise clearly. I have found that some developers are impressively creative and stubborn when it comes to avoiding to work on a ticket that they don’t want to work on. It pays to find out why they don’t want to work on it.
In my experience, it typically comes down to one of the following reasons:
- The task is not clearly described. The developer doesn’t know what she or he has to do.
- The task is too big. The developer knows that she or he will spend a lot of time working on it, and will feel less productive than when working on smaller tickets that can be closed faster.
- The task goes against the developers instinct or preference. For example, I have a developer who consistently avoids working on any Windows-related topic. Because he doesn’t like Windows.
The first two points can be solved by describing a task better, and breaking it down into smaller parts. The third point can be solved by knowing about developer’s preferences and either not assigning tickets to developers that don’t like working on a specific technology or topic, or, if necessary, through sheer force: Tell them to get it over with, repeatedly, until it is done. It might require sitting on the developer until they are done, otherwise they will quickly find a hundred other things that are at least equally important and urgent to work on instead of the task they are supposed to be working on.
Mind you, I am not recommending micro-management. I don’t have the character for it, and most developers don’t work well with micro managers. But I do advocate clarity. Developers should be crystal clear about what they are supposed to do and why they are supposed to do it. A lot of that can be achieved with clear communication of tasks and priorities.
#7 Self-service
Any dependence on other people or teams slows down the speed of any work. Providing tools and services to developers in self-service can hugely speed up their pace of work. Prioritising those services they need more frequently and providing them in a self-service manner can pay off, even if the investment to get there is large.
One significant time sink for developers is the time they spend setting up, maintaining and troubleshooting their development environment, including building and running the software they work on locally on their workstations. Providing standardised development environments remotely, available in self-service at the click of a button to developers, can free up anything between 10-25% of a developer’s time.
Other services that should be provided in self-service to developers are deployment services, e.g. CI/CD pipelines including automated tests that provide feedback to developers quickly.
Conclusion
You need to spend money to make money – and you need to spend time to save time. Identifying the biggest time sinks and productivity blockers will take time, and working to get rid of them will require even more time. In the end, you will earn that time back not just in direct productivity gains, but also in increased happiness and satisfaction. Like most people, developers enjoy being productive and like their jobs better if they feel they are contributing.
