I just finished reading “Deep Work”.  The underlying premise of the book is that to be very successful in the future, you need to be able to learn difficult things quickly, and produce at an elite level, in terms of quality and speed. Further, doing so requires the ability to do “deep work”, defined 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.” This is contrasted with “shallow work: non-cognitively demanding, logistical-style tasks, often performed while distracted. These efforts tend to not create much new value in the world and are easy to replicate.”  While I’d already come across most of the ideas advocated for how to get better at deep work, and do more of it, I thought the book did a good job pulling the ideas together into a coherent package, with concrete advice for how to do the things being advocated.

That said, in terms of applying the advice in the book to my own work, it immediately triggers the question: what qualifies as deep work for a software engineering manager? My current take on this is that doing deep work for a software engineering manager means:

• Learning about (new) technology, thinking about its potential applicability, and evaluating it – does it solve a (technical) problem the team currently has? does it address a customer need? does it enable an entirely new scenario?
• Thinking about ways to improve their team’s software (making it faster/more scalable/more stable and easier to operate/faster to produce), and then making those improvements happen
• Building and successfully advocating for a compelling and ambitious road map for the team, that takes into account customer and business needs and trends, as well as technology evolution
• Finding and hiring great talent for their team
• Growing the skillsets of their team members, and keeping them happy
• Thinking about whether their organization is structured correctly – does each team own the right services/components? Are there new teams that should be formed? Are there teams that no longer make sense?
• Improving the efficiency/effectiveness of how their team operates
• Driving delivery of high-quality software: planning a delivery schedule, staying on top of progress, thinking ahead about possible upcoming issues and developing mitigation plans, continuously verifying that what’s being built matches the requirements etc

The value produced by these tasks is high-quality software that continuously evolves to meet customer and business needs, and an ever-improving team.

Each of these tasks is cognitively demanding and difficult to replicate, because they require one or more of

• The ability to understand deeply technical topics
• A lot of context about the current state of technology, business, or people, plus where things are heading in the future
• Effective project management, including the ability to make creative trade-offs, remove roadblocks, and motivate teams
• Rapid assimilation and analysis of large amounts of data
• Creative and ambitious thinking about how to improve software and processes
• The ability to recognize, recruit, grow, and motivate talented individuals
• The ability to convince others of the merits of an idea being advocated (and incorporate their feedback to improve the idea)

In addition, continuously working on these areas improves your skill by virtue of the feedback cycle: have an idea, try to make it happen, determine whether you got the effect you wanted, learn from the outcome, and start all over again.

Breaking “deep work” down into specific items like the ones listed above has allowed me to explicitly schedule time to focus on each of these areas, to make sure I’m spending time on each of them, and not just dealing with the endless stream of incoming emails and requests (ie “shallow work”). We’ll see how it goes.