Today we continue our series "How to Win with Devs", a sort of "Open Letter" to HR and Engineering Management, with a topic that I believe will meet with one of three possible responses:

1. "You mean there are people who don't do this??? How do they even survive?"

2. "Hmm, I can see how that could work. Thanks for bringing it to my attention!"

3. "This just shows how little you understand about managing people, blink."

Obviously, I'm hoping there's a whole acre of y'all in Option 2!

The Premise

How do you measure your team's productivity?

Method 1: Account for Time

Most of us who have traveled a few miles (ok, ok, I'm just trying to avoid calling myself 'old' here 👨🏽‍🦳) grew up in The Industrial Age, which started in the mid-1800s and carried on for a bit more than a century after that. In this age, people moved from rural life to take jobs in large cities where massive factories created lucrative opportunities.

Factories, of course, run on strict production schedules, and the Industrial Age is therefore tightly coupled to the clock. Everything about the factory subordinates to the timeline, and efficiency is the golden calf at which every organization worships.

These factories recognized two things: (1) They needed people to be at their work stations for a certain length of time and (2) they needed those people to do some amount of minimum output within that time. So they paid by the hour to encourage people to work a full shift, and they provided "standards" for how many widgets or greeps the worker made based on how long it took to make a widget or a greep.

Fast forward a hundred years, and people have been conditioned throughout their careers to "work a 9 to 5", and to put in extra hours to ensure that they've added enough value each day so that the company won't cut them for underproducing.

Method 2: Account for Outcome

Welcome to this side of the year 2000! The Industrial Age has passed and we're squarely in the Information Age. In this period, we're finding that the rules are a bit different:

Software Engineers don't sit in factories and make widgets and greeps. Ok, so maybe writing code looks like "making a widget" on the surface, but the analogy breaks down rapidly, doesn't it? Once one widget is made, you can sell it once. But once a bit of software is made, it can be instantly duplicated over and over and resold an indefinite number of times! Eight hours of coding isn't the same output as eight hours of widget-making; it's exponentially more.

One could argue that the answer to this is "increasing the hourly wage of the programmer"... but what do you increase it to, when you can sell that one product an infinite number of times? We need a different model to keep things fair.

Accounting for Outcomes means that we stop caring about how long something took to do and start caring about whether the desired outcome was achieved. Having a bit of software written is intended to affect the business in a positive way - so we should account for whether that happened, not how long the programmer spent doing it!

Why Businesses Need Method 2

When you measure a programmer by how many hours they work, you're likely to get billed for (conveniently) exactly the number of hours that they need to be paid for. Let's say that I have a coding assignment that's being billed to the customer as a 2 hour job. Let's say I'm a really talented engineer and I solve the problem in 15 minutes.

• Do I charge the customer less because I went faster?
• What do I do with the remaining time?
• Am I going to be paid less because I was more efficient and now don't have work to do for an hour and 45 minutes?
• Is it ethical to slow my output to fill out the 2 hours to keep things kosher between us?
• What happens next week when they ask for something similar and it's given to a junior programmer that takes 4 hours to complete it? Do we charge them more because that person wasn't as efficient?
• What if I got interrupted by a different customer's urgent task - now I have to change streams which means accounting for every minute of my day separately because it wouldn't be fair to use this customer's hour to do that customer's work.

There's another dark side to this model too: Imagine that someone asks me for help with something that I'm not directly assigned to. I want to be helpful and take time to ensure my colleague is successful, but being required to account for my time means that I can't help them unless I have a way to account for that time. This transactional approach to helping a friend decreases collaboration - they're less likely to ask for help, especially if the project is running short on budget... which is when my added expertise would be most valuable! The Industrial Work Model is clearly a terrible fit for the Information Age... yet we continue to cling to it.

Charging the customer by the outcome creates a more equitable arrangement. We tell the programmer "we need x by this date." If they finish early? They can move on to something else. Because the outcome is the same, they're paid the same. If someone needs help from a colleague? No problem, we just collaborate as long as there's slack in the schedule. If the work is going to take longer than we thought? We might have to negotiate the delivery date with the customer but it's not like we have to deal with a changing contract price.

Why Engineers Need Method 2

Now, let's think about this from the engineer's perspective: You've been asked to do a thing, and you've been told when you need to complete it. You're not having to account for the time you spent on that task - which means you actually have more work time in the day rather than having to stop work to record how much time you worked on this or that.

De-emphasizing your work hour count also improves your work-life balance. If you have an appointment in the middle of the day, you're not having to "stay late just to make up the hour you charged to that customer". As long as your work is getting done on time, it doesn't matter if you worked 8 hours today, or 10, or 4. You're less wary of the clock - that's not to say you can just stop working, you still have to deliver your product on time! It's just that 7 hours vs 8 hours vs 9 hours doesn't have any bearing on the contract.

How to move from the Industrial Age to the Information Age

If your Information business still uses Industrial-Age work practices, you might be a little concerned... how can we change something so fundamental to how we operate??? That's gonna take so much work...

Negotiate differently.

The first step is to change your language and the way you form the information you pass to their contract. Instead of giving them an itemized bill of hours estimates, try asking them first when they need it delivered. If the date is unreasonably close, you charge more. If there's more time, you charge a little less. You can still use all the same hours estimates internally at first to help guide your estimation of the actual work, but take the per-hour concept out of the quote. Get them used to the idea that you're surcharging based on how short the timeline is. It makes sense... just like next-day shipping costs more than standard delivery, right?

Free your engineers from the timecard

Unless your engineers are actually hourly employees you should eliminate the timecard at this point. Since you don't have to account for every hour of their work any longer, you can assume they're working a standard week. Your payroll team will find that it's easier to run the process (less variability, less room for error) and your engineers will find that they get time back out of each day that they spent maintaining their timecards (even 15 minutes per day adds up - 4-5 hours per month!)

Jealously guard your WIP Limits, if you don't already

When you're accounting for every hour, it's easy to make the (faulty!) assumption that slicing the pie more doesn't change the size of the pie, and have an engineer who "works on 4 projects each day for 2 hours" that you consider equal to an engineer who "works on 1 project each day for 8 hours". Work In Process (WIP) should be limited as much as possible.

Why?

Because Task-switching is a Time Thief. When you're writing software (or really, doing any task that requires concentration and focus), a brief interruption can pull your brain out of the "flow" state and require significant time to return to that same level of productivity you had before the interruption. Minimizing the number of projects that any one engineer is working on is a good practice regardless of whether you're using a timecard, but limiting your WIP as you switch to an outcome-based measurement model can be a force multiplier.

John Cutler explains this so incredibly well that I almost didn't even bother to summarize the concept here, go check out his blog for details.

Resist the urge to micro-manage.

Once you remove the timecard and switch to a model that doesn't require you to bill hours, you as a manager may feel like you've "lost control".

You have, and that's a good thing.

Why did you need that level of control in the first place? Why did you have to know that your employees were working 8 hours a day? If they can complete all their assignments in 6 hours today, does it really matter that they weren't working for 8 hours?

Allowing your staff autonomy over their schedules will empower them. And Empowered Engineers do amazing things.

But what if they abuse it?

Well - YOU are the manager. Isn't that part of your job... managing? When you see someone who isn't working as much as their teammates, it's your responsibility to make sure they've got plenty of work to do. You just don't have to do it by making sure they're at their desk for 8 hours... you have to do it by ensuring that they've got more stuff in the queue as they finish one thing and move onto the next.

And if they're abusing it egregiously... it's going to show. They'll have so little output that it's clear you're not getting the work out of them that you're paying for. That's why you're a manager... go manage!

Wrapping up

This is an extremely difficult change to make in an organization. I know it's asking a lot to shift paradigms this dramatically, and I want you to know that I'm proud of you for even considering it! I hope I've given you a chance to pause and think about how your measurement practices can have a dramatic effect on your developer team's morale and productivity!