Work Smarter Not Harder: Focus on The Why To Minimize Work About Work

About a month ago, I attended SaaStr, from the comfort of home since the in-person event was postponed back in March. It was my first time attending a full 2-day virtual conference—and I have to admit, I was skeptical. For me, conferences are as much about the energy of the room and the human connection as they are about the information. Love Zoom, but it is a tough substitute.

I quickly found out there were some serious perks. Avoiding a couple of full days of travel on each end, and having the luxury of sitting in my PJs, taking notes, and replaying recorded sessions later was awesome. Ironically, I also found getting to know new people, and especially star-studded casts of speakers like the lineup at SaaStr and most recently, C100's 48 Hours in the Valley, via Zoom, can be very humanizing. Maybe it's just the fact that you get a glimpse into more relaxed work-from-home setups.

One talk in particular that caught my attention was Alex Hood, Chief Product Officer at Asana’s discussion on remote work, and specifically, the idea of work about work. In fact, our partners at Asana have been talking a lot about this recently, and for good reason. 

If you’re not yet familiar with the phrase, work about work is everything that takes time away from the most meaningful work you do. Think menial tasks like setting up your project management system, organizing your team’s workflows (or even just your own), searching for information (what is that doc called again? where do we keep that sheet?), switching between apps, and the really big time suck: meetings to talk about getting work done. I think of it as cleaning the kitchen before you start cooking, and even as you go—it can be included in cooking time, but it's not cooking.

Work about work is also the opposite of deep work—the term to describe focused work on a meaningful task that demands your full, undivided attention. According to Asana's Anatomy of Work Index, knowledge workers spend 60% of their time on work about work, rather than on work that pulls on special skills, and forces you to really think through problems–that’s deep work. While it would be impossible to be doing deep work all the time, 60% on work about work is a lot of wasted time, and I think we can do something about it. 

Across all of the teams at Shift, we spend a lot of time on 'the why.’ Partly, I think this stems from my own hang-up with it; I don’t function well when I don’t understand why I need to do something. When I do understand the why, I can believe in it full-heartedly. What I have discovered about this more recently is that focusing on it early in any workflow cycle is also a very effective delegation strategy because it helps eliminate work about work, before it happens.

Here’s how we do it: for any project spanning, but especially anything that has touchpoints across more than 1 team, we follow the same 4 steps:

1. The Idea: comes from anyone

2. The Build Doc: a defense of the why, and outline of what, who, when, written by the idea-person

3. Content/Design: the work—with full access to the why, at all times

4. Build: the work—with full access to the why, at all times

These steps force us to review the why at all levels and make better decisions, with as little back and forth, or work about work as possible. And what I love most about this approach is that it makes objectives crystal clear, and accessible to all stakeholders, at all times. Anyone can have a great idea and push it through if the why makes sense. Most importantly, it breeds a deep culture of respect. It gets everyone involved and empowers each contributor to make the best possible decision each step of the way, and own the outcome, too.

Across our Marketing, Design, and Customer Success teams, we use Asana to help increase transparency and reduce friction in between the four major steps. On our development team, we use Jira and follow the Agile methodology. As Shift’s Director of Technology, Stewart Lord says,

“Jira is a critical piece of our development lifecycle. With very few exceptions, every feature or fix we build into our product passes through Jira's capable hands. What begins as a question fired off in Slack or a casual suggestion over Zoom must first be turned into a Jira ticket before it can become a change to Shift. We think of them as ‘placeholders for conversations on the why' -once that happens, and the reasoning is in place, we move fast."

One hiccup we’re still working on is finding a way to consistently move more seamlessly between Jira and Asana. Designers and front-end development often get caught in the cross-fire. Luckily, Shift helps with context switching along the way.                               

Finding the right tools, and balance for your team will take some trial and error–and in my experience, there is no silver bullet. What we all have though, is the opportunity to create and nurture an inclusive forum for ideas, where we prioritize access to the why, every step of the way, for all stakeholders, and build scalable processes to keep ourselves accountable.