https://zwischenzugs.com/2021/03/15/when-should-i-interrupt-someone/ Skip to content [4f37af910d] zwischenzugs When Should I Interrupt Someone? zwischenzugs Uncategorized March 15, 2021 3 Minutes How many times have you sat there trying to work through a technical problem, and thought: Is it OK if I interrupt someone else to get them to help me? Pretty much every engineer ever Since I work with companies that are in the process of moving to Cloud Native technologies, there is often a huge gulf in knowledge and experience between the 'early adopters'/'pioneers' and the rest of the organisation. Bridging that gap is a very costly process involving a combination of approaches such as formal training, technical mentoring, gentle cajoling, and internal documentation. Very commonly, the more junior technical staff are very wary of interrupting their more senior colleagues, whose time is perceived as more valuable, and whose knowledge and experience can inhibit them from seeking help. The Problem Most of the time this isn't a huge problem, as engineers negotiate between them when it's OK to interrupt by observing how often others do it, developing good relationships with their peers, and so on. It becomes a problem when people are unable to feel safe to interrupt others. This might be because: * They feel 'left out' of the team * They feel like they 'should' be able to solve the problem themselves * They think asking for help is a failure signal * They don't want to "waste others' time" Job Is 98 Percent Interruption by Scott Adams https://t.co/ 4iqDMwMR9R via @Dilbert_Daily -- Todd (@ToddSRunsIT) June 18, 2019 Of course, all of these reasons are related reasons to do with psychological safety, so often cited as a core characteristic of high-performing teams. This article can't solve that problem, but seeks to help with one aspect of it. If you have rules around when and how it's 'OK' to ask for help, it can make you safer about seeking it. If people feel unable to ask for help, they can (at the worst extremes) sit there sweating for days making no progress, while feeling under enormous stress about their work. At the other end, you can get employees that ask for help after getting stuck immediately, wasting others' time as they have to explain their problem to someone, and very often fixing the problem themselves as they talk. The Rule of Thumb Early in my career, the first consultancy I worked with had a really simple rule for this: If you're stuck for over an hour, seek help. This beautifully simple rule works very well in most contexts. It stops people sitting on blockages for days, and stops them from jumping out of their seat early in a panic. A further piece of advice which I add to this is: When you seek advice, first write down everything you've tried. This has at least three benefits: 1. It acts as a form of rubber duck debugging. Very often, in the process of taking a step back and writing down what you've tried, you'll see what you missed. 2. When you go to get help, you have evidence that you've gone through some kind of structured thought process before raising the alarm, rather than just asking for help as soon as the going got tough. 3. You will save time explaining the context to someone else you've forced to context switch. An essay is not required. Just enough notes to explain clearly and concisely what problem you're facing and what your thinking was about how to solve it. The Formula The rule of thumb is simple and useful, but there's other factors to consider if you want to get really scientific about when and how it's OK to interrupt others. If you're in the business of knowledge work, every time you interrupt someone you reduce their efficiency, and cost your business money. Bosses are notorious for being cavalier with their inferiors' time, but there's often a good justification for this: their time is worth more to the business than yours. So I came up with a formula for this, embodied in this spreadsheet. [screenshot] The formula takes in a few parameters: * 'Time taken thus far' (ie how much time you've spent stuck on the problem) ("T3F") * Time it will take to explain to someone else ("T3E") * The 'interruption overhead' to the interruptee ("IO") * The relative worth of your time and the interruptee's time ("RTW") and tells you whether it's ok to interrupt, as well as how much time you should still spend looking at it before interrupting. The interesting extra parameter here is the 'relative cost' of your time to the interruptee's. This will be difficult to estimate accurately, but it can be set by the more senior staff as a guide to when they want to get involved in a problem. The last thing a more senior engineer should want is for their juniors to be spending significant amounts of time neither solving the problem nor developing their knowledge and capabilities. The formula, for those interested is: Interrupt if: T3F > RTW (IO + T3E) If you use it, let me know! Share this: * Email * * * Tweet * Share on Tumblr * Pocket * * Like this: Like Loading... Related [4f37af910d] Published by zwischenzugs View all posts by zwischenzugs Published March 15, 2021 Post navigation Previous Post An Incompetent Newbie Takes Up 3D Printing 3 thoughts on "When Should I Interrupt Someone?" 1. Pingback: Dew Drop - March 15, 2021 (#3401) - Morning Dew by Alvin Ashcraft 2. [e293e] Oz says: March 15, 2021 at 12:35 pm That's really interesting, but what is really lacking is how do I know how to find out RTW? Most companies don't even have clear ranks. I worked with "Senior developers" who didn't know why they were seniors, or they were really junior. Reply 1. [4f37a] zwischenzugs says: March 15, 2021 at 12:37 pm Indeed. Obviously this valuation is a very political process... A simple rule of thumb you might use is 2x for each 'level' up, making it less time before you approach a peer than a superior. But in reality, you'd probably want to tweak this iteratively as you go per team. Reply Leave a Reply Cancel reply Enter your comment here... [ ] Fill in your details below or click an icon to log in: * * * * Gravatar Email (required) (Address never made public) [ ] Name (required) [ ] Website [ ] WordPress.com Logo You are commenting using your WordPress.com account. ( Log Out / Change ) Google photo You are commenting using your Google account. ( Log Out / Change ) Twitter picture You are commenting using your Twitter account. ( Log Out / Change ) Facebook photo You are commenting using your Facebook account. ( Log Out / Change ) Cancel Connecting to %s [ ] Notify me of new comments via email. [ ] Notify me of new posts via email. [Post Comment] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] This site uses Akismet to reduce spam. Learn how your comment data is processed. Follow me on Twitter My Tweets Top Posts & Pages * When Should I Interrupt Someone? * How (and Why) I Run My Own DNS Servers * Bash to Python Converter * Ten Things I Wish I'd Known Before Using Jenkins Pipelines * My 20-Year Experience of Software Development Methodologies * Ten Things I Wish I'd Known About bash * Anatomy of a Linux DNS Lookup - Part I * The First Non-Bullshit Book About Culture I've Read * Convert Any Server to a Docker Container * Shakespeare's Vocabulary Considered Unexceptional Recent Posts * When Should I Interrupt Someone? * An Incompetent Newbie Takes Up 3D Printing * GitOps Decisions * Five Ways to Undo a Commit in Git * The Halving of the Centre: Covid and its Effect on London Property * Why Do We Have Dev Rels Now? * The Runbooks Project * Some Relatively Obscure Bash Tips * Riding the Tiger: Lessons Learned Implementing Istio * The Astonishing Prescience of Nam June Paik * Notes on Books Read in 2019 * The First Non-Bullshit Book About Culture I've Read * Why Everyone Working in DevOps Should Read The Toyota Way * Surgically Busting the Docker Cache * Software Security Field Guide for the Bewildered * The Lazy Person's Guide to the Info Command * A Hot Take on GitHub Actions * Seven God-Like Bash History Shortcuts You Will Actually Use * How Long Will It Take For The Leavers To Leave? * Goodbye Docker: Purging is Such Sweet Sorrow * Seven Surprising Bash Variables * The Missing Readline Primer * Apple's HQ, Ruskin, Gothic Architecture, and Agile * Eight Obscure Bash Options You Might Want to Know About * 'AWS vs K8s' is the new 'Windows vs Linux' * Pranking the Bash Binary * Bash Startup Explained * Git Hooks the Hard Way * Notes on Books Read in 2018 * Six Ways to Level Up Your nmap Game * Five Things I Wish I'd Known About Git * Eleven bash Tips You Might Want to Know * Learn Bash Debugging Techniques the Hard Way * Why Are Enterprises So Slow? * Anatomy of a Linux DNS Lookup - Part V - Two Debug Nightmares * Anatomy of a Linux DNS Lookup - Part IV * Anatomy of a Linux DNS Lookup - Part III * Anatomy of a Linux DNS Lookup - Part II * Anatomy of a Linux DNS Lookup - Part I * A Docker Image in Less Than 1000 Bytes * Autotrace - Debug on Steroids * Beyond 'Punk Rock Git' in Eleven Steps * Sandboxing Docker with Google's gVisor * Unprivileged Docker Builds - A Proof of Concept * Learn Git Rebase Interactively * Terminal Perf Graphs in one Command * git log - the Good Parts * Five Key Git Concepts Explained the Hard Way * Create Your Own Git Diagrams * Five Things I Did to Change a Team's Culture * Centralise Your Bash History * How (and Why) I Run My Own DNS Servers * Ten More Things I Wish I'd Known About bash * Download a Free Sample of Learn Bash the Hard Way * Ten Things I Wish I'd Known About bash * Project Management as Code with Graphviz * How to Manually Clear Locks in Jenkins * How I Manage My Time * Ten Things I Wish I'd Known About Chef * Vagrant and Ohai / Chef IP Address Hack * 'Towards a National Computer Grid' - Electronic Computers, 1965 * A Complete Chef Infrastructure on Your Laptop * Ten Things I Wish I'd Known Before Using Vagrant * A Checklist for Docker in the Enterprise (Updated) * OpenShift 3.6 DNS In Pictures * Puppeteer - Headless Chrome in a Container * My 20-Year Experience of Software Development Methodologies * A Non-Cloud Serverless Application Pattern Using Git and Docker * Run Your Own AWS APIs on OpenShift * Dockerized Headless Chrome Example * Convert a Server to a Docker Container (Update II) * Automating Dockerized Jenkins Upgrades * Ten Things I Wish I'd Known Before Using Jenkins Pipelines * Five Books I Advise Every DevOps Engineer to Read * Things I Learned Managing Site Reliability for Some of the World's Busiest Gambling Sites * Clustered VM Testing How-To * Easy Shell Automation * 1-Minute Multi-Node VM Setup * Migrating an OpenShift etcd Cluster * A Complete OpenShift Cluster on Vagrant, Step by Step * Learn Kubernetes the Hard Way (the Easy and Cheap Way) * Docker in the Enterprise * Terraform and Dynamic Environments * Bash to Python Converter * Hello world Unikernel Walkthrough * A checklist for Docker in the Enterprise * A Quick Tour of Docker 1.12 * Power 'git log' graphing * ssh -R (reverse tunnel) man page hell * Writing a Technical Book * Interactive Git Tutorials - Rebase and Bisect * Hitler Uses Docker, Annotated * Linux Scales * Play With Kubernetes Quickly Using Docker (Updated) * Convert Any Server to a Docker Container (Updated) * CI as Code Part III: Dynamic Jenkins-Swarm Example * Docker 1.10 Highlights - Updated * CI as Code Part II: Stateless Jenkins With Dynamic Docker Slaves * CI as Code Part I: Stateless Jenkins Deployments Using Docker * Docker Ecosystem Rosetta Stones * Understanding Docker - A Tour of Logical Volume Management * Automating Docker Security Validation * The IT Crowd Was Right - What I learned by reading a lot of RFCs * Understanding Docker - Network Namespaces * DockerConEU 2015 Talk - You Know More Than You Think * Docker Migration In-Flight CRIU * A High Availability Phoenix and A/B Deployment Framework using Docker * Quick Intro to Kubernetes * Take OpenShift for a spin in four commands * RedHat's Docker Build Method - S2I * RedHat's Docker Build Method - S2I * Bash Shortcuts Gem * A CoreOS Cluster in Two Minutes With Four Commands * The Most Pointless Docker Command Ever * My Favourite Docker Tip * Convert Any Server to a Docker Container * A Field Guide to Docker Security Measures * Docker SELinux Experimentation with Reduced Pain * Storage Drivers and Docker * Play With Kubernetes Quickly Using Docker * Play with an OpenShift PaaS using Docker * Scale Your Jenkins Compute With Your Dev Team: Use Docker and Jenkins Swarm * Docker in Practice - A Guide for Engineers * Fight Docker Package Drift! * Win at 2048 with Docker and ShutIt (Redux) * Set Up a Deis (Docker-Friendly) Paas on Digital Ocean for $0.18 Per Hour in Six Easy Steps Using ShutIt * Create your own CoreOS cluster in 6 easy steps for $0.03 * Make Your Own Bespoke Docker Image * Taming Slaves with Docker and ShutIt * Docker - One Year On * Using ShutIt to Build Your Own Taiga Server * Using ShutIt and Docker to play with AWS (Part Two) * Talk on Docker and ShutIt * Using ShutIt and Docker to play with AWS (Part One) * Phoenix deployment pain (and win) * Phoenix Deployment with Docker and ShutIt * Docker, ShutIt and the Perfect 2048 Game (Videos) * Docker, ShutIt and the Perfect 2048 Game (4 - Halfway There) * Docker, ShutIt and the Perfect 2048 Game (3 - Brute Force Escapes) * Docker, ShutIt and the Perfect 2048 Game (2) * Docker, ShutIt, and The Perfect 2048 Game * My Favourite Secret Weapon - strace * Shakespeare's Vocabulary Considered Unexceptional Follow zwischenzugs on WordPress.com Website Built with WordPress.com. Add your thoughts here... (optional) [ ] Post to [] Cancel [Reblog Post] [ ] Email (Required) [ ] Name (Required) [ ] Website [ ] [Post Comment] Loading Comments... Comment x Send to Email Address [ ] Your Name [ ] Your Email Address [ ] [ ] loading [Send Email] Cancel Post was not sent - check your email addresses! Email check failed, please try again Sorry, your blog cannot share posts by email. %d bloggers like this: [b]