Dwight Eisenhower was the 34th president and a five star general in World War II. He won dominated his first election, built the Interstate Highway System, and created NASA. He was quite the productive person. These days, many know him for a productivity technique he practiced known as the Eisenhower matrix.
The eisenhower matrix is based on the principle that we are pretty good at staying busy, but business does not equal productivity. Just because we are doing things doesn’t mean they’re the right things or that they provide value. The matrix splits tasks into four distinct quadrants:
The key here is to be able to differentiate between tasks that are important and those that are urgent. Let’s take a look at a few examples in the software world.
Important and Urgent
Quadrant I tasks are major problems or crises. Most people live in this quadrant and never get out. A development team that spends all of their time here end up stressed and burned out.
Production issues or complaints from big customers cause a never ending spiral. As code is rushed out the door, it inevitably does so with more problems, causing more production problems and more Quadrant I work.
Big project deadlines also end up in Quadrant I most of the time. No doubt these deadlines are urgent and important to the business. Deadlines are necessary and important to the success of the software project. Teams just have to be careful to avoid always working from urgent task to urgent task. Otherwise those non-urgent tasks never get done.
Important and Not Urgent
As Steven Covey, author of The 7 Habits of Highly Effective People, says:
“If something is important, it contributes to your mission, your values, your high priority goals”.
Teams focused here are thinking about their project long term. Often times Quadrant I tasks will force you to absorb some technical debt to get out of a bind. Quadrant II tasks pay that debt off. Refactoring and simplifying the project so teams can support it for years to come.
Scalability should always be thought of, but there is certain point where you don’t need to scale for 10,000 users before you get one. As users start signing up, it’s best to start preparing to scale before the scale problems come up. It may not be urgent to prepare like this, but not one can argue being ready for an influx of users is important to the success of a project.
Not Important and Urgent
Many teams spend most of their time in Quadrant III, thinking they’re in Quadrant I. They are working on urgent matters that actually aren’t all that important. How do you measure importance in a software project? It depends on the project, but it’s easy to take the results from a small focus group and prioritize hundreds of man hours to get done.
Perhaps it’s the complaint of a single user that causes the whole team to frantically adjust an old feature. Without validating that concern with other users, it’s hard to say addressing their concern is more important than the new feature hundreds of users have been requesting.
Users are quick to complain and very slow to praise, if at all. You’ll often only hear the feedback from the small number of users who are unhappy, while not even realizing there are so many happy users. Teams focused on Quadrant 3 are short-term focused and seek the the happiness of these disgruntled users while not accounting for the future.
Not Important and Not Urgent
Teams focused on Quadrant IV undoubtedly won’t be around for long. Working on tasks that aren’t urgent or important is simply irresponsible and does not accomplish anything.
Maybe the teams put their developers in meetings for hours each day. Maybe they’re dealing with paperwork, busywork. Or perhaps they’re just goofing off with their coworkers. Either way, nothing is getting done.
The Goal
The goal is for teams to spend as much time as possible in Quadrant II. I believe successful software teams are focused here as opposed to the other three quadrants. Quadrant I tasks will always exist. No team can avoid them. But prioritization can be done to ensure some time is still being focused on those non-urgent yet so important tasks that keep software projects around for years to come.
