At PagerDuty, we strive to improve and learn as individuals and as a team. This manifests itself through postmortems, code reviews, retrospectives, discussions in Slack/JIRA, and health check surveys, just to mention a few. There are also opportunities to join interest groups, attend sprint reviews, tech talks, and read/write tech blog posts.

As engineers, we’re also tempted to refactor inefficient code, address technical debt, and improve workflows. With so many things that we could be working on (and I haven’t even mentioned our product or infrastructure work within our scrum teams), it’s important to take a closer look at how we are managing our time. For example, what projects should take priority over others and why? What should we work on in order to more effectively move us towards our goals?

Answering these questions requires us to assess the leverage of a given body of work. Leverage, writes Edmond Lau in The Effective Engineer, is defined by a simple equation: It’s the value, or impact, produced per time invested.

In other words, working hard is not the same as working effectively. It’s the difference between being busy and being productive. Another way to look at it is it’s the ROI of engineering. The number of things that we could possibly work on can be boundless, yet our time and resources are limited. Being effective means working on the things that provide the most value while requiring the least amount of effort. The 80-20 rule, also known as Pareto Principle, applies here: 80 percent of results should come from 20 percent of effort.

How Can We Increase Our Leverage?

Former Intel CEO, Andrew Grove, explains in his book High Output Management that your overall leverage—the amount of value that you produce per unit of time—can only be increased in three ways:

1. By reducing the time it takes to complete a certain activity.
2. By increasing the output of a particular activity.
3. By shifting to a higher-leverage activity.

During the day, our time is occupied by a multitude of activities ranging from meetings, checking email, reading/writing text on Confluence/comments/blogs, providing feedback on Github/Confluence, participating in Slack discussions, and sprint work. But no matter what you’re doing, you should ask yourself the following questions to help improve your leverage:

1. How can I complete this activity in a shorter amount of time?
2. How can I increase the value produced by this activity?
3. Is there something else that I could spend my time on that would produce more value?

I’ll provide a few examples below.

Meetings

In order to make a meeting more effective, ask the following questions:

1. Does this meeting need to be an hour long? Can it be accomplished in 30 minutes? Or better yet, in 15 minutes?
2. Are the meeting objectives clear to everyone? Should attendees come prepared with anything? Should they read anything beforehand?
3. Is this meeting even necessary? Can the issue be resolved over Slack or email?

Checking Email and Slack

Emails and Slack preferences will differ from person to person, and there’s no denying that checking and responding to email has value (and the same goes for reading, keeping up-to-date, and collaborating on Slack), but at what point does all this have diminishing returns? In other words, when does it become harmful to our productivity?

With constant interruptions throughout the day, it can be difficult to get to the mindset where you are producing code as fast as this auctioneer can talk. For example, when I’m constantly chattering back and forth in communication tools (e.g., email, Slack, JIRA), then I’m working in a tentative state where I’m constantly Command + Tabbing across different applications, switching between a ton of Chrome tabs, and writing code. Now, I have a system where I try to get at least two to three hours per day of uninterrupted, head-down, locked-in, laser-focused coding time—what I refer to as “deep work.”

Cal Newport, author of Deep Work, defines this as:

“Professional activities performed in a state of distraction-free concentration that push your cognitive capabilities to their limit. These efforts create new value, improve your skill, and are hard to replicate.”

I’ve also heard this concept referred to as flow, coined by psychologist Mihaly Csikszentmihalyi. People who have experienced flow describe it as “a state of effortless concentration so deep that they lost their sense of time, of themselves, of their problems.”

When doing deep work, I normally use the Snooze feature in Slack, which will suppress notifications for a chosen time period. I’ll then check back on Slack periodically when I am at a good stopping point to make sure nothing is on fire.

I believe that engineers do their best work when they’re performing deep work, and I encourage others to try performing deep work for at least one or two hours per day to see if they are more productive. Don’t confuse this with regular/unfocused coding time. Ideally, we should be trying to code throughout the day, but there’s a difference between distracted/unfocused coding and uninterrupted coding—when I say deep work, I’m referring to uninterrupted coding.

The Current JIRA Ticket You’re Working On

Assuming that the Jira ticket has already been prioritized by the product owner and has been through the story time and sprint planning process, it never hurts to take another look at it and see if you can increase its leverage. Let’s gut check it against our three questions:

1. How can I complete this activity in a shorter amount of time?

Can we make use of any already-existing libraries? I know that it can be tempting for engineers to write something from scratch.

2. How can I increase the value produced by this activity?

Is there any way to automate parts of our current task so that we can make it easier for future developers? Can we abstract a common task into a function or class? Sometimes it’s worth investing a little bit of time upfront so that we can iterate more quickly in the future.

3. Is there something else that I could spend my time on that would produce more value?

Are there more important tasks to work on that would be more pertinent to the current goal or release? Think MVP (minimum viable product) in this situation: Do we really need these fancy optimizations in the beginning when we’re just trying to gather early feedback? What’s the smallest shippable slice we can release? What’s the 80-20 on a release? What can we do without? How can we reduce scope without decreasing value?

I know it’s easy to get caught up in busy work. However, I’ve learned that by asking the right questions, you can allow yourself to work effectively and be much more productive.

Stay tuned for Part 2, where I’ll dive more into how to prioritize!