One Advice to Lead Software Projects

Those with a keen eye might find this title familiar. It’s inspired by “The 7 Habits of Highly Effective People.” I used to think that book was a cliche until I read it myself. It’s terrific, and I think we can learn a lot from it, both in our personal lives and our professional lives.

In this series of articles, I’m going to explore some of those habits, and how they can help us lead complex software projects more effectively.

Being Proactive vs. Being Reactive#

Reactivity is our default operating mode. We react to the stimuli we experience around us. We do not initiate in this mode, we merely respond to circumstances. That also means we’re primarily promoting other people’s agendas, as we do not take a stance of our own.

Proactivity, on the other hand, does not come naturally. It requires us to expend energy. It requires us to think for ourselves and decide what we want. Being proactive means taking control of our destiny by taking action.

Most of the time, we’re in reactive mode. It’s not all bad as it helps us accommodate the world around us. You wouldn’t want to be ignorant of what’s going on around you. However, if we are to lead, reacting is not enough. We must take positive action toward a goal. We must be proactive.

Leading Software Projects Proactively#

Let’s say you have a project you want to lead. It’s a complicated project that requires a lot of work. It also necessitates coordination between many different teams. If you remain in reactive mode, a few things are going to happen:

1. You’re not going to have time to work on it, as other more “urgent” tasks will interfere.
2. Other teammates definitely won’t have time for it, as they also have other more “urgent” tasks.
3. Other teams won’t even think of it; they’ve got their own agenda to worry about. The bottom line: your project isn’t going anywhere.

There will always be something more urgent to tackle if you’re in reactive mode. Sometimes, that’s okay. A critical production bug is more urgent and important than a long-term infrastructure project. However, that shouldn’t happen too often — and if it does, it means you’ve prioritized urgency over importance for too long.

In order to prevail over the urgent, we must determine what is important to us. Once that’s settled, we must take action to promote what’s important for us, in this case — our project. That means a few things:

1. Scheduling non-negotiable time to make progress on the project. That way, you’re signaling its importance. You’re also taking control of your time, instead of waiting for others to fill your calendar with their agenda.
2. Making sure other teammates are onboard. You need to make sure they understand the importance of the project, and the part they need to play in order to get it off the ground. That might take some effort on your behalf, as they’ve got other things to do.
3. Making sure other teams are onboard. Different teams often have totally different agendas. You need to make sure your project is on their agenda. If it isn’t, make sure to communicate its importance (more than once, if needed), in order to harness them to the task. The things I’ve mentioned above must be performed consistently. It’s common to be proactive at the beginning of the project. But over time, the default mode creeps in, we become reactive and end up spending most of our time putting out fires.

The Bottom Line#

Reactivity is our default operating mode. It helps us adapt to the world around us, but it’s a terrible way to lead software projects.

To lead projects effectively, you need to be proactive. It’s not enough to plan your project’s execution. You must also schedule dedicated time to work on it, so you can make progress even if unexpected urgencies arise. And finally, you must make sure it stays on the agenda of every one of its stakeholders, inside and outside of your team.