Remote Work: How To Assess Developer Productivity
In our last blog post, we argued that if you want to keep people in a physical office so that you can assess their productivity, then you probably don't know how to assess developer productivity. And obviously, if your job includes managing engineers, that's a useful skill to have.
Remote work's only possible if you can make sense of how much progress your developers are making, whether they're in the office or not. Physical presence is a terrible substitute for trust and insight. So the question becomes: how do you know how your team is doing?
Compare And Contrast
This is what a bunch of productive developers look like<small>Photo by Marissa Anderson on Flickr.</small> in an office, deep into some terribly complex programming problems:
This is what unproductive developers look like in an office, deep into reading some silly nonsense on the Internet:
This is what identical unproductive developers look like while goofing off at home, assuming for the sake of argument that they're all roommates:
And this is what they look like working very very hard from home:
The best way to compare these images is with a quadrant system:
<img src="https://www.pandastrike.com/assets/images/blog/productivity-20150622/quadrant-system.png" style="border: 1px solid black;">
However, if you put them in a coffee shop, you get a similar situation:
And if you run a remote team, and you rent a house on AirBnB so you can all hack together for a week, then it looks like this, whether they're working hard or not:
Finally, this is what it looks like when a bunch of hard-working engineering managers are pulling up commit graphs, doing code reviews, and assessing developer productivity:
Some Experience Required
Assessing developer productivity is easy: look at what's getting done. That doesn't happen in an office, or at home, or in any physical location at all. It happens in a version control system. So even when it does happen in an office, it doesn't.
This part is easy, if you have a technical background. The hard part is you need a technical background. There is this strange idea that you don't need any engineering experience to manage engineers. It's silly. No one would ever think to hire a VP of Sales with no real background in sales, or a CFO who didn't have a strong finance background.
(Actually, companies do sometimes do this, but it doesn't happen often, and when it does happen, it doesn't typically go well.)
A good engineering manager can tell whether the team's getting stuff done because they have the background to understand what is a reasonable amount of work for a team to get done. But non-technical managers can either get fooled by fast talkers or become so cynical that they don't believe anything anyone tells them.
What Happens With Non-Technical Management
Once upon a time, there was a developer who never did any work, but he was so charismatic that no one outed him. We'll call him Mr. Charm.
For a long time, Mr. Charm got away with this, because his CTO didn't realize Mr. Charm's teams were covering for him. However, the CTO did notice that every team Mr. Charm was on seemed to run into endless technical obstacles.
On a hunch, the CTO paired Mr. Charm with a developer—let's call him Hardworky McWorkHard—who wasn't an established friend of Mr. Charm's, and whose teams always got more done than the CTO expected. After a month, the CTO asked Hardworky to do a code review of Mr. Charm's code. But Hardworky McWorkHard came to the CTO privately a day or two later—wrestling with his conscience—and told the CTO that there was no code to review.
So the CTO brought this issue to Mr. Charm, who gave the CTO some explanation about being in a funk and not being motivated and so on. A week later, Mr. Charm resigned.
This isn't maybe the best illustration, since it took a long time for the CTO to finally catch on. But it's worth noting—this was not a remote scenario. And the non-technical executive management still thought it was a big loss when Mr. Charm left.
Non-technical managers are suckers for this kind of thing. Managing engineers based on their body language and tone of voice isn't the best way to go. But the flipside is just as bad: some non-technical managers, since they know they're in the dark, are very suspicious of their engineers. Some resort to overly prescriptive and robotic systems like Scrum.
Either way, that's a problem. Sometimes things that seem simple are actually complicated. Sometimes things that seem complicated are actually simple. If you have a background in programming, it's easier to see which is which. If you think something is taking too long, you ask questions. If an engineer can explain to you what the problem is, fine. Otherwise, you start to zero in on that engineer or team.
But a non-technical person can't make sense of these kinds of explanations. The best they can do is see if it sounds like someone knows what they're talking about. Which leaves their flank open to skilled bullshitters. And thus they end up with the bodies-in-chairs model.
How To Manage Technical Managers
As a team grows, and it gets to the point where you can't really keep track of everything that's going on, you simply put reliable lieutenants in place.
On a motivated team, your best people will hold everyone accountable for you. They will out someone who isn't getting shit done. Especially if you've spent some time developing their abilities to do this. This means teaching them how to provide constructive feedback without being confrontational.
If you hire a team of engineers with a strong work ethic, provide them with reasonable incentives, and help them develop their communication and leadership skills, you don't actually have to do anything else. The team will hold itself accountable.
But a lot of companies just won't do this. They'll violate the No Asshole Rule not just once but two or three times, provide completely warped incentives, provide zero guidance on communication and leadership, and then a non-technical manager will micromanage things to death.
Which leads us to an interesting implication, by the way: there is a massive opportunity cost associated with doing a poor job building the team. Not only will they execute poorly, but a responsible manager has to spend a lot of time assessing productivity. That time is better spent on other things.
This is the reason companies never get around to paying off their technical debt or doing all those cool things they've been talking about and filing under "Someday Maybe": because the leadership of those teams is buried in day-to-day babysitting.
Start with the best team you can. That includes making sure your technical managers have a technical background.