This post is part of a series on The Effective Executive (by Peter F. Drucker). You can find the first post here. In this post I’m going to tackle chapter 5: first things first.
Chapter 5: first things first
Effectiveness is all about concentration. You will achieve your maximum effectiveness by doing the first things first and doing only one thing at a time. Let me explain. If you are trying to maximize your contribution you will find there are always more important contributions to be made than time available to make them. Furthermore, your “major contributions” are no minor tasks, they require all your concentration and strength.
Interruptions, phone calls, meetings, emails, and multiple priorities, especially multiple priorities, disrupt your concentration, fragment your time, and slow you down. I can’t state the importance of doing one thing at a time better than Drucker himself:
This is the “secret” of those people who “do so many things” and apparently so many difficult things. They do only one at a time. As a result, they need much less time in the end than the rest of us.
How to get more time to focus on the things that matter
You need to ruthlessly cut all activities or efforts that are not producing results. How many things are happening in your company because “we’ve always done it that way” or somebody thought it would be a “gold mine” but it turned out to be a “money pit”? If you wouldn’t start that activity again today, it probably has to go. You can’t continue to add tasks to your to-do list indefinitely. You need to cull activities to free up resources and people to go after new opportunities.
With that said, it might not be so easy to cull something that is no longer productive. Drucker warns us about “sacred” projects. Don’t let that stop you from trying to cull them, just realize that you might be in for a fight.
I tried to have one such project culled. It’s one of those things you have to see to believe. Our general manager agreed that we should kill the project to free up resources to pursue better opportunities. But he and I were overruled by the owner who started it. We tried to cull the project again a year or two later and he overruled us again. The best we’ve been able to do is push it into a corner and try to minimize the time and resources devoted to it.
How to identify priorities
Drucker has four rules for identifying priorities:
- pick the future as against the past
- focus on opportunities rather than problems
- choose your own direction–rather than climb on the bandwagon
- aim high, aim for something that will make a difference, rather than for something that is “safe” and easy to do
I’m sure you can think of lots of ways to apply these rules to programming. Let me give you just a couple of examples from my experience.
Pick the future as against the past
This shows up in lots of ways.
As our customers get faster internet connections we worry less about total page size and rendering time on dial-up and slow computers, which was once a major consideration in our website design.
We have a ton of “legacy code” and we’ve been fighting with it for years. We also have a long list of features we would like to add to our systems. We’ve tried various strategies to help us strike a balance between cleaning up our legacy code and adding more features. One of the things we tried was refactoring sprints. They were painful; progress was just so slow. These days we try to prioritize opportunities rather than problems by adding new features when we can and clean up old code only when their isn’t any way around it. We hold new code to a higher standard than old code. That seems to give us the best ROI of anything we’ve tried.
Focus on opportunities rather than problems and aim high
I’m always trying to calculate the ROI of the code people want us to write. We can’t figure things out to the dollar but we can get things more or less in order and that’s good enough. I’m convinced that there are whole classes of problems that aren’t worth addressing with new code.
For example, we have a warehouse where our staff do order fulfillment. The process isn’t as fast as it could be and we often receive requests for code enhancements to make things go faster. The problem is that the cost of staffing and running the warehouse is actually quite small. We only pack orders for 11 weeks in the spring and most of those workers are temporary hires at relatively low wages.
Do you see where I’m going with this? Even if we could make the warehouse operate with zero staff, the total amount we can save is limited by the cost of running the warehouse (it can’t go below zero). But there is no practical limit on how much we can boost revenue. So as long as our system constraint isn’t in the warehouse, it probably doesn’t make sense to invest programming effort there.
Choose your own direction
I once read this article by a business owner who justified waiting a couple of years before adopting new technology. He used wifi as an example (this is a very old example). He said he could rush out and buy all that new expensive gear and have people running around trying to figure out how to install it and get it all working. Or he could just wait a year or two, let the prices come down, let someone else work out the kinks, then hire someone who had successfully installed many wifi systems more complicated than he needed. That way he would be relatively certain he would get a working system at a low price.
I was impressed with how much sense his strategy made. So we’ve done the same thing with our stack. Everything is stable and far from the “bleeding edge.” There’s support and copious documentation online for our entire stack and we don’t have any code locked into abandoned frameworks or languages. We play with the coolest, newest tech in our personal side projects.
First things first vs Theory of Constraints
If you’re following the Theory of Constraints, you find your system constraint and you work to optimize it. Drucker has a slightly different–yet compatible–objective in the bulk of this chapter. He wants us to explicitly cull activities that draw resources away from what’s important. And one way you can figure out what’s important is to follow Drucker’s four steps to identifying priorities. But you could just as easily substitute the Theory of Constraints here and you’d still be on solid ground. The Theory of Constraints doesn’t really say anything about culling projects to make room for new priorities. And, in that way, they dovetail nicely.
You’ll discover your maximum effectiveness when you commit to doing the most important thing first. And then when that’s done, you should review the situation and pick the new most important thing to do and concentrate all your energy on that. To free up your time and resources, you must ruthlessly cull anything that is no longer productive.