In a recent post, we outlined our hypothesis that there are only four ways to reduce the time it takes to complete a project.

One way is to improve developer focus.

(This probably applies to any person working on any type of project, but we’re primarily focused on the world of software development.)

Here are a few ways to improve your team’s ability to focus on the problems at hand:

Have Fewer Meetings

Suppose your team works a typical schedule from 9am to 5 or 6pm.

If you schedule an hour long meeting at 10:30 in the morning, the productivity level between 9am and 10:30am is going to be very low. If you add another meeting at 2:30pm, basically the whole day is wasted.


I’ve worked as an engineer for the better part of a decade. For me personally, if I don’t have a solid 3 to 4 hour block of time for focused technical or creative work, I have a gut feeling that I’m not going to finish whatever I’m working on – even if that’s just the next step in a feature.

Why does that matter?

If you are a deeply technical person, you might have experienced being totally stuck in your head trying to solve a problem. Having to go into a meeting with a difficult problem on your mind can be a bad experience. That said, scheduling sporadic meetings throughout the day is a surefire way to get your team to procrastinate.

The fix for this is to minimize the number of meetings that you have and make sure that your team members each get one or two solid 3 to 4 hour blocks of time without interruption every day.

Eliminate Real-Time Availability (As Much As Possible)

With apps like Slack being so popular, this is not a massively shared opinion. We use Slack like everyone else, and it serves a purpose.

According to research, it takes an average of 23 minutes and 15 seconds to get back on track after you get distracted at work. I’ve felt for a long time that I get more work done in the very early morning hours or late at night that I do when I’m at the office.

This is why.

If I get into the middle of a challenging problem and I’m interrupted with some kind of urgent message, It’s going to seriously sidetrack what I was working on. Also, I’m likely to not be as effective at solving the urgent issue as I would be otherwise.

This is a pretty deep topic, but I’ll offer a few thoughts on how to handle the flurry of communication that inevitably comes your team’s way.

First, systematize important communication channels. For example, bug reports should come through a bug tracker, not by random communication from management or customers.

Second, define specific times where people have the ability to ask questions and share information. This can help minimize people being constantly interrupted with questions.

Last, have a clear definition for what is urgent. Most problems can wait four to eight hours to be discussed. If you’ve established specific times to communicate like the last point suggests, you can just wait a little while instead of breaking someone’s focus to get an answer now.

Create Clear Targets with Inflexible Deadlines

As we walked through in our discussion of complexity, problems often have a myriad of solutions – some of which are much more complicated and time consuming than others.

Creating an inflexible deadline forces people to focus and figure out solutions that can be achieved during that time period. Given an undefined amount of time, it’s easier to wander into more complicated solutions. Often times complication is actually more interesting to engineers, and so there is a silent gravitation in that direction. Fixed deadlines help to offset that.

But what happens if you don’t hit the deadline?

That’s up to you. Some companies will actually scrap the work in order to avoid throwing good money after bad. The truth is that it depends on the problem. If it’s hyper important to the business, obviously you’ll need to solve it. However, the cutoff point functions nicely as a moment to reconsider the problem and make sure you’re team is approaching it from the right direction.

If you decide that they are, that’s great. You just estimate how much time is left and set a new deadline. On the other hand, two months worth of work isn’t that much in the grand scheme of things. If you need to pivot, it’s not the end of the world. It’s not great, but it could be much worse.

Need Help?

We are a full service software engineering firm. We can help you with everything from design to project management to development.

Got a project you’d like to talk about? Get in touch at