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.
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.
Latest posts by Mike Hansen (see all)
- Nexus Firewall – Quality at Velocity - February 1, 2017
- The Reports of Agile’s Death have been Greatly Exaggerated - June 22, 2016
- The Low Cost of High Caliber Developers - March 7, 2016
- The Nexus Firewall – Perimeter Defense for Software Development - November 18, 2015
- Software Supply Chain Automation - May 13, 2015