Ask a dev manager Time management

How to deal with interruptions?

Interruptions are the bane of the creatives and yes, that includes you, software engineers of the world. Let’s dig a little deeper into why interruptions are bad by explaining “flow”

What is flow?

Flow is a mental state that allows for deep concentration on a task without noticing the surrounding environment or the time.

Think of the last time you began work, looked at the time, and 3 or more hours had passed and you did not even realize it.

Why is it important?

For anyone involved in engineering, design, development, writing, or similar work, flow is your most productive time and for the vast majority, it is the only way to “get anything done”.

The above statement usually surfaces as a comment saying “I can’t get anything done from 9-5”, or your team deciding to work early or stay late just to accomplish anything meaningful.

The problem

In a normal 8 hour day, engineers and everyone else, are at odds on how to best utilize their time.

Managers, Product Managers, Executives, Sales, and most everyone that needs something from Engineers thrives on a day full of interruptions. Meaningful work for non-engineers looks like constant interruptions, status meetings, impromptu discussions to come up with action items, and similar items. We pride ourselves on the fact that we can keep track of 10+ things in our heads. For proof, just look at the calendar for anyone not doing software engineering.

Exaggerated calendar view for a manger

This interruption driven style of work then permeates to the daily life of our engineers, and soon enough, their calendars start looking like the one above, Yikes! and we dare to wonder why the engineers “don’t get anything done”

What can we do about it?

The first step is to measure the interruptions, then take action.
A really good starting point as mentioned by Tom DeMarco and Tim Lister in Peopleware: Productive Projects and Teams (3rd Edition) is to measure the proportion of uninterrupted hours to total hours, they call it the e-factor as in “environmental factor

If you buy the idea that a good environment ought to afford workers the possibility of working in flow, the collection of uninterrupted-hour data can give you some meaningful metric evidence of just how good or bad your environment is.

Whenever the number of uninterrupted hours is a reasonably high proportion of total hours, up to approximately 40 percent, then the environment is allowing people to get into flow when they need to.

Much lower numbers imply frustration and reduced effectiveness.

We call this metric the Environmental Factor or E-Factor.

(Tom DeMarco and Tim Lister, 2013)

The number might be low, to begin with, but constantly watching the e-factor and aiming to increase it, should lead to new measures to reduce interruptions being introduced

How do we get better?

When it comes to actual action items, your team will know best. Talk to them, experiment, and measure your team’s e-factor constantly.

To get started, here are some practices that have helped teams around the world:

  • Introduce a strong commitment to quality, which reduces support, and thus reducing interruptions
  • Time management techniques such as
    • Pomodoro
    • Block “maker time” in your calendar
    • Turn on do not disturb settings on your phone and computer
    • Visible chat signals so others know about “flow” time
  • Writing objectives on paper before starting work
  • Knowing and practicing when and how to say no, or better said, “not now, but let me get back to you”
  • Email rules to surface important items and hide or delay “noise”
  • Separate machines for work and personal use
  • Quiet environment

For more great ideas, see Scott Hanselman’s productivity tips

Best of luck and happy “flow”

Icons made by Darius Dan from www.flaticon.com

Ask a dev manager

I hate estimates, help!

Our first question of the week was more of a statement “I hate estimates, help!”

Lucky for you, there is a lot of help in this area.

let’s start by understanding why you are being asked for estimates, and then move on to some quick types of estimation you can try within your team.

Why estimates?

short answer, decision making.

long answer estimates help the company make decisions by understanding the possible return on investment for any given work.

Estimates answer questions such as

  • should we take on the work? We might not be getting our money’s worth
  • when can other work start? There is only so much you can do
  • can we meet the promise sales already made? – we all love this one
  • should we hire? There is a lot of work to be done, promises made, targets to reach… estimating is a visual input into determining if hiring is needed.
  • when will it be done? Mainly because people just want to know, it feels good to know.

now that you understand the importance, let’s move on to how you can go about simplifying your estimation process

What is your unit of measure?

When asked for an estimate, you are not being asked for story points, or a number of tickets, or engineer hours… You are being asked for a date for your changes to show up in production.

While your answer is a date, how you get to that date is another matter, and it will most likely vary based on your process

Knowing your velocity

The first step is knowing your velocity. Velocity measures the rate at which things make it to production. These “things” can be measured in different ways such as

  • The number of tickets, where all tickets look roughly the same and you count how many tickets you complete on a given period
  • Story points, usually following the Fibonacci sequence to denote relative effort and you count points for a given period
  • Ideal hours, where you are asked to throw a number of hours for development work, then measure how many of those you get through on a given period
  • T-shirt size is another relative estimation technique, where a t-shirt size directly maps to a set number of days you believe it will take to complete

Just pick one that works for you and stick to it. For the rest of this story, I’ll use the the number of tickets just to keep things simple.

Your first estimate

Following with the ticket example, let’s say you get through 10 tickets in one month, this is your velocity (Great work by the way)

You are then asked to estimate a project and after going back and forth on the details, you believe you can break it down into about 20 tickets, so you blurt out “two months”

Is that it? could it be this simple? possibly, all estimates need to have a confidence level. It might be OK to have low confidence in your estimate to begin with.

Confidence levels in estimating

Now that you said two months, are you willing to put two months from today on a contract with monetary contingencies if the date is not met?

Probably not, and the reason is that the confidence level on the estimate is low.

To increase the confidence level on the estimate, you can work your way through questions such as

  • Do I know the start date? most work is not of a “drop everything and do it now” nature. Figure out how much longer before you can start on the new project and adjust your estimate.
  • Do you know your velocity fluctuations? December is usually slow, the summer sees a lot of vacation time, there might be a seasonality to your business to account for. Use this information to update your estimate
  • Was it 20 tickets? take some time and do a Work Breakdown Structure exercise. You will probably end up with more tickets than you started with.

For more ideas on increasing the fidelity of your estimate, take a look at Software Estimation: Demystifying the Black Art (Developer Best Practices)

As a rule of thumb, when providing your estimate, be clear about the current fidelity of it.

Always ask if you should spend any time getting a better fidelity estimate.

Your time is valuable, besides, you can always point your boss to this article and have them help you out 🙂

Go for extra points

Project Software such as TeamGantt allows you to easily visualize project plans.

Go ahead plug in your start and end dates for your tickets and surprise your boss with a beautiful graph

Icons made by Eucalyp from www.flaticon.com
Ask a dev manager


Or should I say hello world!

welcome to the wonderful world of management, specifically, managing for software engineers

Technology, process, team building, mentorship, hiring and firing, SDLC and plenty more will make their way to this blog

We answer questions as well, all sorts of questions, no topic is off limits here.

Head over to our “ask a dev manager” page and ask away!

Once again, Welcome to this wonderful world, enjoy your stay

Icons made by Freepik from www.flaticon.com