An exercise I like to do is to try to categorize the typical day to day tasks in terms of the time frame they are responding to. I actually feel that this says a lot about the company’s culture and way of working.

From this point of view, a task can be:

Being reactive

I’d say that this is the most common type of task. Something happens and we need to react to it. Typical examples are those related with production bugs. We have a bug report, depending on the severity, someone needs to attend to it.

Another scenario is when something comes up that is very important. For example that quick change that is required for the marketing team to launch that campaign and track something. Or something else that someone might have forgotten.

Another example that might be more controverse: when a developer finishes a task and goes to the backlog to grab another one. In this situation the task itself might not be reactive but the process of finishing something and grabbing what’s next in line favours reactiveness.

Being proactive

Proactive tasks start with someone solving a problem and building up an idea. It’s about what we can do now to achieve something in the future. This is more about having a vision for what’s to come. Note that we always have someone thinking on these tasks:

  • Could be the product team considering the next steps
  • Could be a team leader planning a feature

These tasks may require research and discovery. We need to start with an idea for something that isn’t defined yet, that we may not know if it’s possible at all, and invest time in making it real.

It’s for example not only solving a bug, but going after the root cause. Or when we know that someone is depending on us, trying to make a plan to resolve dependencies sooner. Or registering our own ideas on the backlog.

Forecasting

This is much more rare to see. It’s when someone has the responsibility to forecast what we’re going to look like in 6 to 12 months for example. If proactive tasks are about having a vision and start working towards it, forecast is to pinpoint the future and figure out where we’re going to be at.

(See software engineering KPIs.)

What kind of features are we going to have? What kind of performance requirements will need to be addressed? How many clients are we expecting? What teams will we have? How will we structure our teams? How many developers are we going to have? What will our infrastructure look like? How many instances are we going to need?

It’s very tricky to gather this information and naturally there’s a lot of guessing. But this is a very interesting exercise. When we force ourselves to detail concrete outcomes of our vision, we’re actually putting it to the test and will need to face some problems that we might not want to at the moment.

When we forecast a goal it opens up our options though. If we have a picture of what’s ahead we can start being proactive today to accomplish that tomorrow. We can analyse if that forecast is ambitious enough and if it’s not, then we can change things now.

Summary

We should start with forecasting, then being proactive and then reactive. This could be from top to bottom. The company’s leadership does the forecasting, then middle management is proactive and finally developers react to it. Or we can have autonomous teams that do it all.

Do note that all types are important. If we’re just forecasting and being proactive we’ll leave little room to react. For example, if developers are doing some creative work on creating something new, but are interrupted to take care of a bug, their productivity will suffer. But bugs do need to be addressed. Investing in having some people focused on being reactive pays off.

At the end of the day what I think defines a company is the amount of people we have on each task at a given time. This will be changing every day. But we need to be careful not to be stuck on reactive land.