Overseeing Remote Developers? Don’t Even Try

Author, Mike Hansen

Author, Mike Hansen

I recently presented with Mark Kilby at a webinar sponsored by Atlassian.  It was a great turnout with a live audience close to 1,000 and nearly 3,000 registrants overall.  There were a lot of questions from the attendees covering a broad range of topics, but one very common question was “How do you ensure your developers are performing given everyone is remote?”

That is a pretty intuitive question.  With people spread out all over the world and no one walking by their “cubes” during the day, how in the world can you know that they are working hard?  The counter-intuitive thing is, as the head of engineering, I don’t ever think about that, let alone worry about it.

Why is that?  I hadn’t really thought much about it until I saw how many people were interested in the answer.  My rather subjective view follows.

Extend Trust

When you have a completely virtual team with everyone working remotely, you have to extend a high-degree of explicit trust to the members of the team to start.  There is just no way to watch over what people are doing, which frankly, is a bunch of useless management overhead anyway.  Rather, there is a general assumption that people are going to do the right thing.

That’s not going to happen if people are dropped into a vacuum, of course.  But, having the right environment within which they can work creates a key part of the necessary conditions for success.  As I discussed during the webinar, if you make sure people have what they need and ensure they know where they need to go, you just need to get out of their way.

The Right People

There is one other important part here too:  You need the right people.  This is a topic for another post entirely, though there is one aspect that is directly applicable here.  You have to have people that are self-driven.  Nearly every job description contains that requirement, and it’s kind of ridiculous to have to state it for any kind of knowledge worker role.  But, how do you filter for it?

In the case of our hiring practices, I think there is a bit of an implicit filtering process that is occurring.  Working with a completely distributed team is a pretty bold concept currently, though it is becoming more and more prevalent because of the access to talent the model provides for small to medium sized organizations.  When candidates hear about it, some just don’t like the implications.  How am I going to get my questions answered quickly?  How am I going to get the support I need?  Those folks need not apply.  But, the people that do self-select in, are at least implicitly stating that “I have what it takes to work on my own and am confident I can succeed independently.”  Individuals that require a lot of handholding and guidance are not going to succeed in a remote context, at least not in Sonatype’s case.

Was this person a good hire?

My sense is that people that readily embrace the notion of the remote work environment are much more likely to be self-driven and highly motivated.  While I do not have a scientific basis for this assertion, I do have empirical results to support it.  We have had a 100% success rate in hiring as measured by answering the question “Was this person a good hire?”  I can’t imagine being able to hold that metric indefinitely, but I am certainly not going to complain in the mean time.

With the right people in the right environment, you simply don’t have to worry about individual developer performance.  This requires that an effective agile discipline is in place, providing the inherent checks and balances overall — i.e. the regular introspection and assessment through daily standups, sprint reviews and retrospectives.  With teams filled with “the right people”, no one is going to be able to hide habitual or recurring non-performance, even if “the wrong person” were to make it past our recruiting filters.  Remote developer performance is one less thing for me to worry about.

The following two tabs change content below.

Mike Hansen

Head of Products at Sonatype
Relentlessly working to surround myself with technical people better than me, making sure they have what they need to excel and when appropriate, quickly getting the *#$& out of the way. And, when not busy doing that, playing the piano or looking for the next Colorado 14er to climb (30 bagged to date).
Authors

Related posts

4 Comments

  1. Craig Erickson said:

    Implementing a change management system is one of the best ways to oversee developers’ performance whether remote or not. As a project manager, I prefer to collect metrics on build status, test case results, incident reports, and elapsed time between tasks begun and tasks completed. Then I send these status reports to developers and ask them to correct anything they think isn’t representing the great work they are doing, and any challenges that they had to work through. You can call it continuous improvement, agile deployment — anything but a “performance audit” — because the goal is to improve the process so DevOps can fulfill their potential, instead of getting blamed personally when things go wrong.

  2. Robert Reiz said:

    I absolutely agree with the article. Just one thing I would like to add. Working remote works the best if everybody is remote. Or at least the big majority of the team. If every single team member works remote, the whole team is forced to use the same tools for communication and documentation. In that way everybody is equal. If 90% of the team works in the same office and only 2 guys work remotely you will have the problem that the office workers will do a lot of undocumented discussions in the coffee kitchen. They will make undocumented decisions and the 2 remote guys become the outsiders.

*

Top