Top 4 Tips for Managing Remote Developers

At least half of the reasons why software projects fail owe, one way or another, to poorly defined project requirements. We discuss this with respect to due diligence in Software Project Success – 5 Keys of Responsibility. Due diligence or properly defined project requirements are critical whether you are working with an all in-house team, developers working from home, or a team distributed across several time zones. Poorly defined project requirements can lead to changes in a project’s tech stack, languages, features and components, and more – midstream in its development. This delays projects, makes them more expensive and more prone to miss critical deadlines, and can kill projects outright.

1. Product vision and mission – a) what will the software do, b) who is it for, c) why will people want to use it, d) what data will it collect, e) what metrics will be used to evaluate its success? Product-market fit (c) is itself extremely important and the driving factor for most Minimum Viable Products. Data collection options deserve extra attention by checking with all business stakeholders to identify all of the data your software can collect. In some cases, business data is actually worth more than your B2C products and services.
2. Project requirements checklist – This covers the techstack that will be used for your project – all of the technical services it will use, programming languages, list of modules and features, to include tools, libraries, frameworks, API’s, and a list of the devices it will support. This extends further to maintaining industry awareness of likely changes, for example when Google and Apple decided to stop supporting 32-bit apps when transitioning to exclusive support of 64-bit apps.
3. Scope of work – It’s entirely possible that when working in a distributed environment that you may have several teams working on portions of the same project. Or you might have one development team for the coding and a designer for the UI/UX. Strive to be very clear when and where each team’s work starts and ends. This ties into using project management software, suffice that you probably don’t want to pay for duplicate efforts.
4. Coding standards – Probably the best way to enforce coding quality is to have a clearly defined coding standard. More time will be spent by your team reading than writing code, so it makes sense to have everyone use the same style guide/s. It may seem like a lot of extra work, but there are a lot of ready-made resources created by other companies to simplify the process.

Software developers tend to spend a quarter of their time in meetings. These include sprint-planning and reviews, grooming, stand-ups, retrospectives, but also code reviews. Some distributed teams may have members in several time zones and separated by up to 12 hours which can complicate scheduling. While meetings are very important for purposes of communication, they do cut into productivity. It’s wise then to establish a consistent protocol in the scheduling, conduct, and attendance requirements of your meetings.

1. Strive to have weekly meetings on the same day and time each week, excepting holidays. Similarly, schedule daily meetings at the same time each day. The goal is to create a regular pattern which also helps to make sure everyone comes prepared, avoid scheduling conflicts and interruptions.
2. Assess and clearly designate every team member who needs to be present for each meeting. Record meetings so anyone who misses it, or doesn’t need to be present, can still stay up-to-date.
3. Avoid spur of the moment meetings. Try to provide at least 24 hours of advanced notice for special or ad hoc meetings. Specify the topic and any reports, documentation, or information any team member is expected to provide. This provides everyone time to review and prepare so decision-makers can make informed decisions in the meeting vs. needing to schedule another meeting.
4. It’s a good practice to designate a substitute to deliver the meeting on behalf of the official organizer. The higher their office the better the practice. C-Levels and Senior Managers often have other meetings that go overtime.

Software development teams should always be striving to improve their efficiency. If you can save team members 30 minutes of meetings per day so they can code more, that’s a potential 12.5% boost in productivity.

Insanity. Here’s a list of the top 20 project management software (PMS) solutions. Here’s another list with the 41 “best” PMS software and tools. It’s clear that the majority of them only please some project managers some of the time. Basecamp, Zoho, Trello, Jira, Asana, Monday, Wrike… it’s no surprise that some small teams are still using MS Excel for everything. A colleague of ours recently noted how one startup had changed its PMS four times in as many months.

Our stance is that the more mature the PMS is, the less likely it is to blame (most of the time). Most of the issues with PMS programs boil down to poorly defined tasks, team members skipping some or all tracking notes, and sometimes lacking features. Switching project management software can be a lot of work – and will often lead to a repeat of the same problems you were trying to escape.

The solution? Training. Instead of switching your PMS, define your standards, train your team to your standards, enforce your standards, and make sure everyone knows how to perform all the functions they need in your PMS. Use links and files (like Google Sheets/Docs or another Office Suite everyone has access to) to handle anything your PMS can’t.

Most (70%) of software developers use Git as their Version Control System (VCS). With Git, developers also use services like GitHub, GitLab, Bitbucket, and Azure DevOps to help manage git repositories and team collaboration. Going one step further, some companies use services like WayDev, Gitential, GitLean, and PinPoint to track software developer performance.

Some developers find software development analytics KPIs and metrics controversial. But a good engineering manager will find the automated data provided over time indispensable. Obviously, the project requirements, size, scope, and complexity of software projects vary from one project to the next. This can make it difficult to compare a developer’s performance from one project to the next, or with another developer.

Even so, performance analytics can provide an enormous amount of insight on developer performance and project progress. They track a wide range of metrics related to:

• Speed (velocity, pushes per day)
• Quality (code churn, defect ratios)
• Efficiency (throughput, code efficiency)
• Collaboration (review coverage, responsiveness)

All of which can be used to define where improvements can be made. Some developers may be fearful that performance analytics will be used to punish them – which simply doesn’t factor into the equation. With such a high demand for software developers and IT specialists in general, companies want to help their developers improve their skills. It’s hard to improve what you can’t measure.

If you keep giving work to your best developers, eventually they’ll get overloaded and their efficiency will decrease. Some amount of code churn is inherent to every project, but it should decrease as the project gets closer to launch. If it fluctuates, it could mean that a developer hasn’t used a particular programming language very often, has perfectionist tendencies, or a variety of other root causes. Ultimately, for the long-term, software development analytics provides managers data they can use to optimize their team for any given software project or task. But it can also be used by managers to assign mentors, code review partners, and quantify improvements over time for new (and experienced) developers.

While these cover the most important and most common issues faced by most teams, remote or not, you may have unique challenges of your own. If so, we’d love to hear from you – maybe we can help. Please use the form below to drop us a line and we’ll respond at the first opportunity.