How you can Better Manage Developer Productivity

Productivity is a huge part of a company’s success. You could have a team of the most driven, self-motivating and consistent developers, but if you don’t give them the right working environment, their productivity will eventually break down.

Manage Developer Productivity

What many authority figures fail to overlook is the most important variable of any business, the human factor. Focus, comfortability, scheduling, hardware, and communication are all aspects that are within your control and should be cared for.

Like most CEO’s or upper management within web development companies, you’re likely to have a developer background. Remembering this point in your career should add empathy towards your development team, think of the problems that affected your productivity and recall what changes you wished management would have made. Of course, your current teams’ problems will be different from yours. How can you find out theirs? Ask! It’s the quickest way to discover what is affecting their productivity, but you have to make sure the setting is comfortable, as they may be criticizing your own work practice.

Here are a few factors we practice at CodeClouds to ensure a productive working environment for our development team.

Meeting Times and Meeting Quantity

For developers, becoming truly focused takes time. This issue becomes even more complex for global development companies who are negotiating different time zones. It can be difficult to identify a time that won’t hinder productivity for at least one party involved.

Meeting Time and Meeting Quality

The general trend with developers is that they need large chunks of time to fully immerse themselves and work through the task at hand. Therefore, your meeting times should optimize the day’s potential for large portions of time. Which usually means, either first thing in the morning or around lunch time, where they can take their break after a meeting and have the rest of the afternoon interruption free.

Scheduled meetings are necessary, there’s no getting around that. It’s where major decisions are made, project statuses are checked and suggestions are made to create better future outcomes. But you should acknowledge that too many meetings can be disruptive, they will stop a developer from completing their own work, inhibiting deep thinking and business growth. Therefore, it’s important to optimize meeting productivity itself. Firstly, you should ask yourself whether a meeting is actually needed:

  • Will other communication methods, such as email or Skype result in the same outcome?
  • Who in the meeting truly needs to be there? Do you only need to cover certain developer projects for now?
  • Don’t let the meeting drag on. If everything you set out to achieve has been covered quicker than you estimated, end it there. Don’t let off piece spontaneous concepts take up unnecessary time, they can be dealt with in the future when you’ve formed more meaningful thoughts.

In these meetings, you should be setting reasonable deadlines, avoiding undue scope creep, and overall avoid constantly changing the nature of the project or piling on more work on a regular basis. These actions will disrupt the development cycle and lead to unnecessary stress as crunch time nears and everything has to be uprooted. This means the earliest meetings for a project are the most important, and these meetings should focus on laying out a realistic timeline with plenty of room for unforeseen changes to the project. Input of the people actually working on the project is important here, make sure they are comfortable speaking about a deadline or change that they feel is unrealistic.

Work Environment

A productive work environment can refer to the overall feel of the workplace and the individual experience each developer has on a day-to-day basis.

For some, natural white noise like vehicles passing, rain falling or the dull hum of a fan helps by masking other background noise. Of course, what’s adequate white noise will differ with each individual. This is why employees should feel comfortable wearing headphones and listening to audio that helps their mind enter an effective state, while some who prefer not to should have a relatively constant level of soft noise. The key is to minimize sounds in the office that interrupt white noise, therefore breaking developer concentration. This involved anything that will cause your mind to recognize a new pattern, such as someone talking, or a chip packet crinkling. Therefore, keep water cooler conversation in a separate room where employees can briefly socialize or snack without affecting anyone else.

Much more important than noise is distractions. Bothering other people at their desk when it could have been a message or an email is disruptive. This should be a consideration when planning the office space itself. Do you really need a hip and modern open office, or would the type of tasks in this department be better suited for traditional dividers or cubicles with plenty of desk space and privacy? What do your developers want? Some people prefer and open office, but others simply hate an open office. Both office types have their positives and negatives. If it’s the type of environment where people wear headphones even if they’re not listening to anything to avoid others bothering them, it might be time to consider change. I work in the New Zealand office at CodeClouds, where the general layout would be described as open, however, developers have the option of entering another room if they require more seclusion.

Further, developers should feel confident personalizing their own workspace. Whether that be adding something they find encouraging, visually appealing or refreshing. This usually involves a family picture, a bouquet of flowers or air freshener. Whatever they decide to include, just ensure that it doesn’t hinder anyone else.

Lastly, keeping the workplace clean should be a standard, cleaners should visit the office on a regular basis, preferably after office hours.

Avoid Micromanagement

Micromanagement is an infamous term. Most people associate it with negative behavior from a higher authority. This is fair enough, but there’s definitely a difference between a micro-manager and a manager who is providing meaningful guidance and support to developers. A positive micromanager provides support to influence a successful outcome, without controlling the developers involved.

Avoid Micromanagement

The negative and most common form of micromanagement forces developers to be as unproductive as they possibly can. Constant planned and unplanned interruptions mean a developer will never fully focus. Overt monitoring and paranoia will cause developers to be scared about making suggestions and contributing towards solutions. Micromanaging undermines a developers skillset! Ask yourself why you hired them in the first place if you don’t acknowledge their ability? This quickly leads to a complete loss of trust and will quickly cause talented developers to quit.

Provide Adequate Hardware

Simply put, up to date, fast equipment is vital to the productivity of a developer. A mini cooper has no chance of winning a sports car race, no matter how good the driver is. Why? Because the technology surrounding them have limited their productivity. Your approach to your development team should be the same, recognizing that the best tools for iOS developers will mean something different to Shopify developers.

Again the most important thing is to ask and identify the preferences of each developer. Hardware requests might involve SSD’s, more screens, specialty keyboards which you should have policies about (sometimes keyboards are too loud), internal networks or power needs for specific projects. iOS developers may need a mac for Xcode. Ask your developers what they need, then ask your IT team how to make it happen and how to make their jobs easier as well.

Let’s consider any moment during development where things have to buffer, build or run and for a short period of time the developer will have to wait before proceeding further. With adequate equipment, a developer may only have to wait 5 seconds, with inadequate equipment this could be 5 minutes or more. An extended period of time means that the programmer is likely to lose focus. What else can they do in that period of waiting anyway? Not to mention that amongst aggressive deadlines, slow technology can be irritating. Further, investing in the best hardware will likely save organization money through increased productivity and morale as well as making upgrades a more long term planned process instead of an emergency requirement one day.

The common trend in this piece is that you should never expect superhuman focus. “Superhuman,” meaning not human, meaning not real, meaning not your development team! Developers are known to be efficient and diligent, but they are not robots and should never be treated as such.

All the concepts above are of course contextual and what works for CodeClouds developers may not work elsewhere. Therefore it’s important you are connected with your development team, opening up avenues for them to make suggestions and create solutions. The greater understanding you have of your team, the more relatable you are and the more comfortable they are to share.

Lastly, an outstanding work environment attracts more talent. Developers are an online community and word gets around about those companies who value their team. Growing your reputation from a humanitarian perspective makes job openings sought after. Upon company expansion, you can hire app developers, CRM developers or web developers quickly and with greater quality assurance.