VictorOps is now Splunk On-Call! Learn More.
I don’t know how the term “shaving the yak” caught on, but I’m willing to embrace it for all of its weirdness and meaning. We all spend a lot of time on tasks that don’t directly relate to some meaningful objective. Sometimes they’re useful, but far removed from the impact they deliver. Some tasks, such as setting up Trello to better manage my blog posts, can result in hunting down some obscure integrations with IFTT or Zapier and getting those to work.
But, oftentimes, these tasks really are just pure distractions. These distractions can be super dangerous, especially in the application development world where execution is based on heads-down dedicated work. Depending on the extent, these distractions can be highly costly and dangerous.
To get the real coding done, the nature of application development is that you need to be heads-down and laser-focused on your code. On a good week, the percentage of time where work actually happens is often less than 30%. Leading to my ultimate point – modern work culture is interrupt-driven. And, we, collectively, are to blame, although there are several drivers.
1) We’re really just avoiding work. This is a reality we all have to admit, people sometimes avoid work. And, when we do, we’ll briefly embrace meaningless tasks as a distraction. The problem being, those meaningless tasks take a life of their own once they’re fed with any amount of energy, and then they self-propagate. For, example if you take on a task that isn’t directly related to your work and you do it well, the next time something similar comes up, you’re on-call for that as well.
2) Our peers are also avoiding work and trying to get you to support their cause. Your peers will leverage your time to support their avoidance of doing heads-down work as well. It can come in the form of simple questions that seem harmless. Or, it can start with a funny observation about something that becomes a rabbit hole – like a weird Tweet about your product where you feel the need to start a Sherlock Holmes-type investigation.
3) Techies are fixers and they want to help. Techies like to have answers to the challenges they’re faced with, even if those challenges have nothing to do with them or their work. So, when the default answer should be ‘No’, it’s usually a hesitant ‘Yes’. But, then there’s potentially a complete focus on something that may not benefit anyone long term.
Most of the time, the distractions that you’re brought into and entertain are your own fault. That’s how “culture” forms. The nature of development work is partly to blame for allowing an interrupt culture to exist but it’s the people that feed it. And, when I think about it, I can’t think of one person I know who isn’t guilty of feeding the fire, some more than others. This interrupt-driven development culture also means the solution isn’t always going to work for others, it’s going to be your own. Own your productivity, and stop being interrupted.
There’s the obvious cost of wasted time that comes from the interrupt culture. Most interruption costs come in the form of delayed features, frequent bugs due to lack of continuity between tasks and time spent working on tasks that don’t impact the bottom line of the organization. But, there’s also the costs of your morale and downtime, which can be even more expensive. Despite the fact we can logically recognize that we’re guilty of feeding the interrupt culture, emotionally we like to blame our environment. And, this long-term thought process creates resentment, and that resentment leads to feeling unproductive and unhappy in the workplace.
There’s no easy solution, not one that I’ve found, at least. Solutions are often different for every individual. For me, avoiding interruptions is about being aware when I’ve allowed interruption to interfere with my work. And, while the following solutions aren’t always clear-cut or perfect, I’ve still found substantial benefit toward minimizing the impact of interruptions on my heads-down work with these practices:
I spend time deliberately creating guardrails for myself, such that the effort to embrace an interruption is more than I’m willing to invest and creates enough of a buffer to say, ‘No’. For example, a buffer could be dedicated devices for specific use cases. My current attempt at this is to turn my iPad into a blog-only device. It has no other apps than what’s needed to write blog posts. My 13-inch Mac Pro is for dev, dark mode and all. And, last but not least, my 15-inch Macbook Pro is for work only: email, social media, etc., ideally reducing pretty much anything that could be a distraction. Finally, I’ve dedicated my gaming life to console only now, so my PS4 is the only place to go for that entertainment.
You don’t need to make enemies by saying no to everything that comes your way. One simple thing I’ve found is to get yourself invited to fewer meetings and be on fewer email distribution lists. Don’t join Slack channels unless it’s necessary, it can create a lot of over-notification and anxiety. Any and all of these are time bombs for current and future interruptions.
If you’re the source of interruptions, try to stop yourself, and if you sense yourself going down a path of meaningless yak shaving, put on the breaks. This is just an awareness issue that stops the compounding of the interrupt culture for yourself and for your peers.
It’s worth being said that a lot of work isn’t heads-down and much of it is collaborative. Development is a very focused task but program increment planning, for example, is super collaborative – an interruption that can actually serve to create energy and ideas.
This is meant to be a bit of a new year’s resolution “Rah, Rah!” post to help developers get to what they enjoy most, and get them back to doing what they love – writing code and building functionality. It takes a very deliberate effort to stay focused on building functionality in our ever-increasing interrupt-driven work culture.
During the course of writing this post, I was interrupted 3 times, was the interrupter 5 times (when I think of something funny I just have to share). And, my context switched twice – causing the most disruption to my thought process.
When disaster strikes and an incident occurs, you can’t afford numerous interruptions or a loss in productivity. Try out a 14-day free trial of VictorOps to see how automation in on-call schedules and alert routing is driving rapid incident response.