In part one of this two-part series, I went over focusing on low-effort tasks that produce the highest value and ways to increase leverage in some of your everyday activities. To quickly summarize, leverage can be defined as value, or impact, produced per time invested. In other words, the ROI (return on investment) of engineering. While increasing leverage is a good measuring tool, it may not always be clear how much value, or impact, a given task will produce. And sometimes, with the sheer number of tasks thrown in your face, it can be difficult to prioritize.

As an engineer, there are so many things to work on, right? Although our sprints may be organized into bite-sized tickets, we should consider organizing our own tasks that fall outside of sprint work. These could be things like reviewing a document in Confluence, writing documentation, or reviewing code from another team. From my experience, when these items pile up, it’s likely other things will slip through the cracks.

Enumerated below are some best practices for managing a huge list of tasks, accessing their priority, and evaluating the short- and long-term gains of a given task.

The Simple Checklist

This is probably obvious, but a simple checklist can help keep track of non-sprint-related work. It can be as simple as a document in Google Drive, a handwritten list on paper, or even the use of productivity apps like Wunderlist or Todoist. Seeing everything written down can give you a sense of what the most important things are and what’s not even worth doing.

Having a checklist can also help identify what to work on in between tickets or during small blocks of time in between meetings. But how can we determine which tasks or items have more value than others?

What Work Produces Value?

Engineers are really good at solving problems in the product and engineering space. We spend a lot of time figuring out things like efficient ways to implement a feature, how to compose different systems, and discovering optimal ways of storing and passing data, just to name a few.

Beyond the scope of adding engineering value are things that also add business value. This can include users acquired, products/features shipped, business metrics moved, processes/systems optimized, and sales made. These things are more important than hours worked, lines of code written, meetings attended, and JIRA tasks completed.

With this in mind, we as engineers should try to focus on tasks that not only help engineers and our users, but also help the business.

Learn to Say No

As an engineer, there is a balance that can be quite difficult to master—such as managing sprint and non-sprint work, helping people, collaborating with other people/teams, and continuing professional/personal development. Often, we can get invited to things like non-team meetings, interest groups, and to review other documents. The inviters are usually unaware of the opportunity cost of our time.

As such, it’s important to learn to say no. Because our time and resources are limited, not every invitation should be treated as an obligation. While it would be nice to attend all of these extracurricular activities, they can sometimes detract us from our other tasks. However, if these invitations are of high priority, then that should definitely be discussed. But since we cannot work on everything, we must focus on what matters—and that means focusing on what produces the most value.

Focus on the Important and Non-Urgent

Because we’re constantly hit with email, Slack messages/requests, bugs, and incidents throughout the day, we could become more reactive instead of proactive about our work. We should be careful as this will make it difficult to focus on longer-term investments like learning new programming languages, continuing professional development, and building relationships.

Every activity can be partitioned into four quadrants based on their importance and urgency (which should not be confused as synonyms). Take a look at the Eisenhower Matrix below:

Most of our time is normally occupied by Quadrant 1 and Quadrant 3, which fall under the “Urgent” column. However, when we focus too much on these quadrants, we neglect the non-urgent but important activities in Quadrant 2, which includes things like:

• Career goals and building strong relationships
• Reading books and articles for professional development
• Building tools to improve our workflows
• Learning new programming languages, libraries, frameworks, etc.
• Mentoring our teammates to help them be more productive

Quadrant 2 investments often don’t have any deadlines, so they won’t get prioritized. But in the long run, they provide significant value because they help us learn and grow both personally and professionally.

When dealing with your personal checklist, be sure to find which of your to-dos fall in Quadrant 2 and de-prioritize things in Quadrants 3 and 4 that aren’t as important.

Invest in Team Growth

One Quadrant 2 activity that I think has high leverage and that we can improve on is team growth, which can be defined as growing our engineering team in terms of people and in our knowledge and processes.

Hiring and Onboarding

Hopefully, most engineers are regularly participating in interviewing engineering candidates. It helps when everyone can share the load on this. Most, if not all, engineers should take part in the interviewing process to help keep a strong engineering culture intact. A lot of teams also suffer from being understaffed, so bringing in more talent will definitely help in the long run.

Once new hires are brought in, a thorough onboarding checklist should be available to help enable the new engineer to be productive as quickly as possible. This checklist should be constantly improving as each candidate goes through it and makes modifications. But one thing to always keep in mind for the onboarding process is: How can we help engineers quickly ramp up on a particular technology or system?

Spreading Knowledge

I think this is one area where all companies can improve on. While we have things like interest groups, tech talks, blog posts, documentation in Github and Confluence, and postmortems, information is usually scattered. For example, if an engineer wants to learn about Ember.js from the ground up, it would be nice if we could simply refer them to a page that has high-level explanations, as well as a set of coding exercises to help them ramp up.

At Google, they maintain a resource called CodeLabs to explain common abstractions used throughout the codebase, as well as provide code walkthroughs and exercises to help solidify the concepts. Even a baby step toward this could be very beneficial.

I have thought a bit about this area of spreading knowledge and have two suggestions about how to improve. I hope that these suggestions can help engineering organizations come together as a group and decide on some standards for effectively spreading knowledge.

Two Ideas for Spreading Knowledge

1. Leverage Interest Groups

Interest groups are typically formed around a particular technology, language, framework, etc., and are open for any engineer to join. The goal of an interest group is to help engineers learn and collaborate around a specific topic (for example, Elixir, Ember.js, etc.) in an attempt to help other teams work effectively with that technology. They can create documentation that could be consumed by engineers who have never had any experience with the given technology. The documentation could include a series of documents, screencasts, code exercises, and links to resources. Interest groups can also think about future investments into the given technology.

2. Use Mentors

Engineering organizations are normally filled with engineers that have expertise in a variety of different technologies, whether it’s MySQL, Javascript, or Python experts, just to name a few. Most of the time these engineers are extremely busy pushing the envelope with product features. Wouldn’t it be nice to have a program where fellow engineers could get some mentoring from these experts?

A mentor/mentee model for a given technology could be a great opportunity to work with engineers on other teams, as well as give engineers opportunities to mentor and/or learn. This could be one 30-minute meeting per week where the mentor can answer any questions and provide resources to aid in learning for the mentee.

Some of these are probably in place within your current engineering organization, but how much time and effort is being invested in it? These activities, while may seem to detract engineers from their immediate obligations, can actually yield long-term value.

Further Reading

These are just a few ideas I had on how we can become more effective engineers. A lot of these ideas were inspired from The Effective Engineer by Edmond Lau and Deep Work by Cal Newport. If you’d like to read more on the topic of being an effective engineer and staying focused in a distracting world, I’d highly recommend these.