We maximize what we measure. Without clarity on purpose, we measure the things that make us feel good. These pleasures distract us from deriving joy from what we maximize. In short, we (I) tend to focus on the input more than impact.
By understanding how to define and measure productivity for ourselves, we reset our focus.
First we will define productivity, then we will understand how to use all sources of information, last we'll look at 6 lenses we can use to view our own productivity and how we can "clean the lense" to have a more clear picture.
Defining productivity
If we define productivity as "the ability to have impact," our metrics for whether we are productive are subject to the context in which we operate.
Put another way, there is no consistent metric we can apply to understand whether we are productive.
Furthermore, "productivity" is an attribute. Just like kindness, intelligence or attractiveness, we cannot measure productivity on our own.
Likewise, exclusively allowing others to define our productivity will give us an inaccurate result. Much like looking in a foggy mirror.
Example
I once took on a large-scale, highly-visible project. I collaborated across every team in our org and delivered the first milestone before the deadline.
After I delivered the first piece, the project was cancelled. We had many things in place which no longer served a purpose. Leadership saw the delivery as a win. I saw it as a failure.
From that anecdote, should I say that I was productive because I delivered on time? Productive because leadership saw it as productive? Or should I say that I was unproductive because my time did not end in driving impact?
We must use all available signals to point us towards some sense of true productivity. In this case, two of the three signals I can identify say I was productive. From these signals, I can look for lessons to take forward.
It can be useful to group these signals into internal productivity (ones own view) and external productivity (others view). "Cleaning the lense" of internal productivity is about honestly measuring our impact against an idealized self. For external productivity, it is about empowering those around us to speak to our productivity accurately.
Both are vital to success.
Internal Productivity: Incremental delivery
To understand what we've done and how much we've done, we need to mark it as done.
Said another way, until something is released, it does not speak to our productivity.
Release more often! Break down your work into smaller pieces! When I started doing this, I noticed that I became much more relaxed as a developer. Because I could see how much I'd done, I became more satisfied with how much I was doing. I am also able to push myself to get more done because I tackle a smaller scope at any given time.
Work items can also become too fine grained. The rest of this section is dedicated to understanding what is too large and too small.
A change is too small when it cannot be reviewed without reviewing another change. A change is too large when a comment could block part of the release, but other parts could go out.
I worked with Cory, a good engineer who advocated for 75/75 PRs: 75 lines of code and 75 lines of tests in one pull request. For me, 150/150 is about right. If you're over 300/300, you can probably break things down more.
Kent Beck also gave us one of the best tools for refining this skill in Test Driven Development: By Example. Write a list of things you'll do in the next hour and a list of things you'll do in the next month.
By writing the list of tasks you'll do in the next hour, you're breaking your work into smaller-than-hour-sized-chunks. If deploying one task is not a large enough scope, you can group tasks together into a deployment unit.
This technique is also the easiest way to know your timeline, which we'll talk about soon.
Internal Productivity: Unblock Yourself
At face value, "unblock yourself" is a truism. In practice, when I see someone stuck at a junior-level of productivity it's usually because they don't know when to ask for help or they don't know how to unblock themselves.
Software is a collaborative activity. The only stupid questions are those asked insincerely (yep, there's a story there). The idea of "unblock yourself" is not at odds with asking for help.
When you feel blocked, put in two hours of concerted effort. During the two hour window, continually come back to the question, "ok, but how do I move forward?" If you are tempted to stop pressing forward, imagine that everyone else is on vacation (yep, there's a story there too). If that doesn't help, type out the question you'd want to ask in specific detail and imagine what the person would ask you to try first.
At the end of the two hour window, reach out to someone. If you want to go the extra mile, continue to work on the problem after you've reached out and race to solve the problem before the person responds.
There's no secret here. It's effort. Regardless of outcome, stretching yourself like this strengthens the muscle that leads to productivity.
By attempting to unblock yourself, you're implicitly asking the question, "how would my idealized self solve this problem?" Year over year, you will see a trend of being able to solve larger problems without being blocked.
Internal Productivity: Foreknowledge and experience
This lense speaks to how quickly and accurately you can respond to a given situation. By understanding how large the boundaries of your knowledge are, you can more clearly understand how far you have to go to respond well.
Measure how often you can identify gaps and how well you can expand your borders of knowledge to grow beyond the gap. Every time you find something new and relevant to learn, celebrate.
One day I was brought onto a project. We were integrating with a new downstream system that didn't have an established RPS limit. We wanted to know for sure the system could handle our load.
The week prior I took the time to learn k6. As it turned out, I had the clearest vision for how we could move forward load testing this downstream system. Because I spent time to learn something, I was able to propose a solution. I didn't know I'd be on the project. I didn't know the project would need load testing.
How did I know a load testing tool was the right thing to learn? I listened to the wind (most people call this prayer). That answer probably isn't satisfying though, so here are more concrete steps you can take:
- Listen to what others are interested in and ways they've solved problems.
- Look around for the holes in how your company does things. Instead of learning a specific technology, evaluate several.
- Aim to spend a certain percent of your time learning things. Google calls this 20% time, several people in my community call this Fun Fridays.
Especially the last point is important. If you feel consistently overwhelmed by everything in front of you, slow down. This not only allows you to continue learning, but often gives room to gain perspective. It's a lot like driving, if you only look 5 feet in front of you, everything requires a quick reaction. If you gaze down the road, you'll be able to take your time to react in a more measured manner.
Don't aim for always being "right" about what to learn next. Focus on expanding the boundaries of your knowledge and skill.
For the experience part of foreknowledge and experience, find developers who are better than you and get on projects with them. There's nothing quite as helpful as observing and adopting how others approach problems. If you can't find anybody more senior, find someone more junior. Junior engineers don't have the years of bias you do and there's a lot one can learn from fresh eyes.
External Productivity: Align with Impact
I know a number of developers who don't care about the business side of business; they just want to write code, architect solid systems, and sleep at night without alarms going off. We need people like this on our teams and in our lives.
One common expression I hear from this archetype is that the business doesn't see how productive they are. This is true - the more technical a deliverable, the less likely a business will be able to evaluate its importance.
You must bridge the gap. Define the exact impact of any piece of work you propose. Impact must be related to customer experience, money, or a measured reduction in operational overhead. Unless you find something else the business cares about, ruthlessly de-prioritize anything that doesn't fit into this list.
Once you've gone through this exercise a number of times, you may notice the things that "business people" propose also align with this list almost all of the time. Speaking in terms of impact unifies the two "halves" of the company.
Note: extensibility is intentionally left off the list. If you want to change something for extensibility, include the effort as part of the effort for a business feature. In general, this is a good way to take care of tech debt.
External Productivity: Measure the Unknown
When I was younger, I once estimated that a piece of work would take me 2 months. 6 months later I delivered it. In addition to failing to deliver incrementally, there were unanticipated, external factors preventing me from moving quickly.
Developing skill in estimating, and especially measuring the unknown, is essential to having others reflect back your productivity accurately. Promise to deliver only what you know you can deliver and expose the unknowns that make timelines risky. When you find out your timeline is wrong, expose it as early as possible.
If you're a younger developer being asked for timelines, look for older developers and ask for their opinions. Be aware that, according to The Mythical Man Month, coding is 1/6 of the time it takes to get something to production.
There are a number of circumstances which cause unknowns to creep into the schedule:
- When something is unknown because you haven't broken down the work, break down the work.
- When it's because the logic is not define yet, the services are unfamiliar or, there's new (to you) algorithms / technologies, estimate with that in mind.
Estimate unknowns first in terms of scale. Will it take hours, days, weeks, months, or years? Then give an "expected" and "if everything goes wrong" estimate.
When you dive into the project and the unknown becomes known, expose early when something will take longer than expected. This develops trust.
By measuring the unknown, we eliminate a common reason it's hard for others to help us evaluate our productivity. Measuring the unknown brings others in to the conversation about how long something will actually take instead of having a binary yes/no for if a deadline will be met. This allows other developers to speak to us for how we are managing our time.
External Productivity: Know your timeline
Know your past. It allows others to reflect back a more accurate representation of your productivity during a performance review.
Know your present. It allows you to accurately reflect back to others what you're currently working on and prioritize new initiatives against current ones.
Know your future. It allows you to not slow down when you finish a project and cast vision to others when it's time to move on from your current initiatives.
Again, as Kent would say, the easiest way to do all three of these is to keep two lists. One list of things you'll do in the next hour and another of things you'll do in the next month. Ticketing systems like Jira most often don't encompass what we do. Take note of things like the conversations you need to schedule and one-off tasks which so often encroach upon our time.
Summary
There's no easy answers. Productivity is ephemeral. Stay present, stay curious, put in the work. Seek to use all sources for a sense of true productivity.
Top comments (1)
Thanks for writing this Bob. I appreciate your open approach to growth and learning.