Michael designed solid software systems and wrote clean code. He enjoyed working on both technically interesting problems as well as hygienic refactors of the codebase. And over the years, Michael had climbed the engineering ladder at a top Silicon Valley tech company to become a senior engineer.

But one aspect of his work ethic made him difficult to work with and actually held back his career growth. He eschewed any work not directly related to code. Any time a project involved coordinating with another team, sharing a design document to get feedback, or prioritizing what to work on next, he would retreat back to the comfort of his code and program more instead. His projects’ progress would often stall and take much longer to ship – as a result, his tech lead couldn’t entrust him with higher-impact projects without also prodding him to actually work on critical, launch-blocking tasks.

Unfortunately, Michael’s mindset that he should only focus on deep, technical problems is common among many engineers. Believing that success rests solely on your technical laurels limits your career growth. Your ability to create meaningful impact in your job relies on other, less deep work as well.

Focusing on Deep Work Is Necessary But Not Sufficient

In his new book Deep Work, Cal Newport introduces the term “deep work” to describe the professional activities you do that challenge your cognitive capabilities — they’re the activities that require focus and concentration, free from distraction. For an engineer, deep work might be coding or designing a product or system. For a researcher, it might be working out the details of a theory or conducting a lab experiment. For a designer, it might be weighing different user requirements or iterating on a user interface.

Deep work contrasts with “shallow work” — the logistical tasks you do every day that aren’t intellectually challenging — and Newport argues that you ought to ruthlessly shift time in your schedule from shallow work to deep work. To equip you for that transition, he documents techniques that he’s developed to maximize his output, from meticulously planning out his day to abandoning social media.

In a world where our days are frequently dominated by a whirlwind of emails, meetings, web surfing, and other distractions, carving out time for deep work as Newport suggests can be extremely valuable. Our small team of 15 engineers at Quip is able to be extremely productive partly because we don’t use email internally and usually hold no more than 1-2 meetings per week. As a result, we’re able to reclaim more time for deep work.

But a focus on deep work at the expense of other work has its limits, and in Michael’s case, actually exacted a large toll on his projects. Reasoning in terms of deep versus shallow work isn’t the best framework for maximizing impact.

A much more powerful framework is leverage, which measures the impact that you produce per time spent. The highest-leverage activities — the activities with the highest return on your time investment — may include deep work, but they also include logistical-style tasks such as planning, prioritizing, and coordinating your highest-impact projects. These logistical tasks might be shallower, but they can significantly amplify your impact.

And so, while the ability to focus on deep work is an important skill, there’s actually a related skill that’s even more valuable: the ability to own your problem and your results.

Own Your Problem and Your Results

One of the hallmarks of an effective engineer — or any professional for that matter — is the ability to take ownership of a problem and to do what it takes to deliver a solution. These individuals make strong teammates, as they can be entrusted to follow through on the question: What needs to get done for this project to succeed?

A belief that all shallow work is categorically unimportant — for example, that a software engineer should only focus on coding and design work — impairs your ability to tackle that question. Oftentimes, the key task required to successfully move a project forward might be shallow, unglamorous, or not intellectually challenging.

That task might be coordinating with your teammates to ensure everyone is prioritizing the most important work.

It might be gathering customer feedback to ensure you’re building the right solution.

It might be following up with a designer or an engineer on another team to see whether she has time to complete dependencies you need and whether she might become a bottleneck.

Or it might even be standing in line to get approval from a key decision maker for a launch. In Marissa Mayer and the Fight to Save Yahoo! author Nicolas Carlson recounts the office hours that Mayer would hold during her time at Google. For many years, she was the gatekeeper for user interface (UI) changes on google.com, and everyone from engineers to vice presidents would line up outside of her office for a 5-minute slot to get her sign-off for upcoming launches. ¹

It’s an experience that I was intimately familiar with — my team had to sign up for her weekly UI reviews when we were launching query refinements ² and other user experiments on google.com. Was waiting in line a deep, technical challenge? No. Was it unfortunate that decision-making was bottlenecked on a single person? Yes. But was it a high-leverage investment of time for our team to line up? Absolutely — Mayer’s approval was the price of shipping our months of engineering effort and impacting millions of users. That’s not to say we didn’t also try to streamline the process, but we also accepted that any process change would take a long time.

In these different cases, even tasks that aren’t particularly deep, technical problems can be critical to effectively executing on a project. When you own a problem, you make sure that you or someone else takes care of those leverage points.

Ultimately, if you want to maximize your effectiveness, don’t think solely in terms of deep work versus shallow work. Focus instead on the highest-leverage tasks that must be accomplished to get your job done. The most effective engineers own their results — that means having the technical skills to execute on deep work, but also having the meta-skills and the willingness to tackle any shallower tasks necessary to translate that work into impact.