fbpx

Category: Ask a dev manager

Categories
Ask a dev manager

Working half days

Both my wife and my mother-in-law are visiting family in Mexico, while I’ve stayed back to take care of the kids while they go to school.

Instead of taking two weeks off, I decided to work half days. There were some interesting finds that I would like to share with you here today.

Focused

My days have been highly focused. I start the day by waking up at five AM, getting the kids ready for school, preparing breakfast for myself, going to the gym, and listening to the latest audiobook.

I do all of this in about an hour and a half every morning before opening my computer to start work.

During the period, I have set up timers to make sure that we have breakfast on time, brush our teeth on time, and leave the house with enough time to get on the school bus.

It gives me enough of a window for me to go hit the gym in the morning and then make it all the way back home, shower, and start the workday.

Once I open up my computer, I do about 15 minutes of reading to catch up on Yesterday’s happenings or anything else important that might have happened in the company.

I then move on to a couple of one-on-ones, and then I spend the last hour before I close my computer writing up documentation and replying to relevant conversations.

I usually have a to-do list that grows every day, and I’m sure many of you can relate to this, but since I have a tight time constraint of only half my day, I feel the urgency to ruthlessly prioritize my to-do list. 

If I see something in there that was nice to follow up on in the past, I just mark it off and remove it from my to-do list, or delegate it to someone, or delay responding to it.

This framework of delete, delay or delegate is something I have used in the past, but it kind of went sideways as of late.

With my new time constraint, I only get to work on what truly adds value. Everything else is deleted, delayed, or delegated.

Fewer meetings

My typical day today is full of meetings, but since I’m working half days, I just canceled out all the meetings I had and only kept one-on-ones.

I was worried about this. It is different when you take vacation time, and then there’s no expectation that you’re doing any work whatsoever. 

For this, it’s different since I am present in Slack, and people can see me replying and actually working on initiatives, headcount planning, half of the year planning, and all the other fun stuff we do as managers.

But it turns out that not going to the meetings it’s ok.

I have been able to catch up on the topics and provide my opinion.

I have been able to follow up on projects, I have been able to understand the context, I have been able to participate in planning activities, and I still feel like I know everything that is going on. 

Now I have to say that I feel lucky I can do this because my current employer has an excellent remote working culture.

Every meeting is documented, and I can watch recordings at two or two 1/2 times the speed to get myself caught up with what was said at the meeting.

Keep one-on-ones

Now the meetings I did not cancel were mainly one-on-ones.

First, I believe one-on-ones are extremely important, and they deserve my full attention.

When I was thinking about priorities, one-on-ones were always top of mind.

Second is that given that they are one-on-ones, there are only two of us involved, so it is a lot easier to move around when compared to a regular meeting.

Conclusion

So far, I like this experiment. 

I have found out that I am ruthlessly prioritizing now, really using my delete-delegate-delay framework. 

I am also learning that I can stay up-to-date on most topics without having to meet

Lastly, I end up prioritizing face time for my one-on-ones.

Icons made by Flat Icons from www.flaticon.com

Categories
Ask a dev manager Time management

How to deal with interruptions?

interruption

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

Categories
Ask a dev manager

I hate estimates, help!

estimate

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
Categories
Ask a dev manager

Welcome!

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