How to be judged by your output, not your time in the office
If you want to limit your working hours as a programmer you need to keep your boss happy. But what can you do if your boss seems to care more about your time in the office than how much you produce?
Not to mention the comparison to your other coworkers. If they fix ten bugs a week, but you only fix two, your boss might not be happy—even if the bugs you fixed had far more impact, and were much harder to address.
If you’re stuck in this situation it may seem impossible to reduce your working hours. But before you give up and start looking for another job, it’s worth seeing if you can improve the situation where you are.
Two reasons your boss might like long hours
If you’re going to be judged by hours you need a manager who cares about the organization’s or team’s goals. There are two possibilities about how your boss is thinking:
Hours as proxy: Your boss cares about achieving goals, and is using hours as a mental shorthand for value produced. If you actually are a valuable worker, and make sure they know it, they won’t notice your working hours, as in this real occurrence:
A programmer I know was having a conversation with their manager when the manager mentioned, in an offhand manner, that the company expected people to work 50 hours a week.
This programmer had always worked 40-45 hours a week, and the manager had never complained or noticed, because the programmer did good work. So the programmer kept their mouth shut, didn’t comment, and kept on working their usual hours.
Hours as goal: Your boss may truly only care about hours in the office number of bugs fixed, or some other irrelevant measure. Which is to say, they’re incompetent. In this case the suggestion that follows won’t work, unless perhaps you can bypass your boss and reach someone who does care about organizational goals. Usually a job with different team or organization will serve you better.
Assuming your boss only uses hours as a proxy measure, let’s see what you can do.
Starting with goals
It’s 3PM on a Wednesday, and your boss swings by your desk and asks how things are going. You explain you’re upgrading one of your JavaScript dependencies.
Your boss nods and wanders off, wondering if you’re actually doing anything worthwhile. You have just wasted an opportunity to demonstrate your value.
What’s the alternative? Starting with goals in mind.
Elsewhere I’ve talked about how starting with goals in mind will keep you focused, and is key to making you more productive. Starting with your organizational and team goals in mind can also help you both choose valuable work and explain its value to your boss.
For every task you work on, you should have a clear logical path from the big picture organizational goals, down to your team’s goals, down to your project’s goals, down to why this particular task at this particular time is a good way to advance those goals. If you can’t make that connection, if you can’t explain why you’re doing what you’re doing:
- You may not actually be doing anything valuable.
- Even if you are, you can’t prove it.
Let’s get back to that JavaScript dependency. If you started with goals in mind you might have decided this wasn’t a particularly useful task to begin with, and worked on something else. Or, perhaps you know exactly why you’re doing it.
In that case, the conversation might go something like this:
“You know how we’ve decided we wanted to increase user retention? Well, it looks like one of the problems is that our site is rendering way too slowly, so half our users bounce before the page finishes loading.
Turns out that font loading is the problem, and this library has a feature to fix that in its latest release. Once I’ve upgraded I should be able to get pages to render in a quarter of the time, and I’m hoping that’ll increase user retention. And I have some other ideas in case that isn’t sufficient.”
Your boss goes away understanding that what you’re doing is valuable. And if they’re anywhere near competent they won’t be thinking about the bug queue, or how many hours they’ve seen you in the office. They’ll be thinking about the good work you’re doing, and how they can tell their boss that the retention problem is being addressed.
Communicating your value based on goals
You can explain your work in this way when asked, but there’s no reason not to do so proactively as well. Once a week, or once a month, you can take stock of what you’ve achieved and send an email to your boss. And you can also keep a copy of this email to update your resume when the time comes to look for a new job.
To recap:
- Understand why you’re doing your work.
- Choose work that addresses those goals.
- Communicate to your boss why your work is helping those goals.
This will shift many managers from a hour mindset—driven by an assumption that your work isn’t producing that much value—to a value mindset. Your boss will know your output is valuable, and as a result won’t require the proxy measure of hours worked.
Learning how to work towards goals is, of course, easier said than done. It took me many years and many mistakes along the way. If you’d like to accelerate your learning, and take advantage of everything I’ve learned working as a programmer over the past 20 years, you can sign up for my Software Clown weekly newsletter. Every week I share a mistake and what you can learn from it.