Learn how to be a wildly successful small business programmer

What you should know about the Effective Executive: part 1

The Effective Executive by Peter F. Drucker is one of my favorite business books of all time. It should be on every 10x programmer’s reading list for two reasons. First, it offers knowledge workers (including computer programmers) a guide to becoming ridiculously effective. Secondly, many millions of business people have read this very influential book and by reading it, you will gain insight into how many business people set priorities and approach their work.

No matter how good of a programmer you are, I promise you that you can get better by reading this book and applying its lessons.

The Thesis of the Effective Executive

Drucker’s thesis is that effective executives have many different styles but they share several characteristics. They:

  • ask “What needs to be done?”
  • ask “What is right for the enterprise?”
  • develop action plans
  • take responsibility for decisions
  • take responsibility for communicating with the people around them
  • are focused on opportunities rather than problems
  • run productive meetings
  • think and say “we” rather than “I”

If I can quote from the book for a moment: “The first two practices gave them the knowledge they needed.  The next four helped them convert this knowledge into effective action. The last two ensured that the whole organization felt responsible and accountable.”

If that sounds promising, keep reading. I’m going to write about one or two things from each chapter of the Effective Executive that I find particularly applicable or interesting in regards to programming. It’s a big topic so I’m going to tackle one our two chapters per post and turn this into a series.

Chapter 1: effectiveness can be learned

Drucker argues (and I agree with him), that effectiveness is the result of making a habit out of a series of practices that influence effectiveness. Your intelligence is relatively fixed and you probably didn’t get to pick your co-workers or your boss but you can practice the habits of effectiveness. These habits include:

  1. knowing where your time goes
  2. focus on results your customers care about
  3. build on strengths (your own, your co-worker’s, your boss’s, your company’s)
  4. focus on a few major areas where superior performance will produce outstanding results
  5. making effective decisions

So wherever you are on the effectiveness spectrum, you can always improve.

Chapter 2: know thy time

Everyone gets the same 24 hours each day. You get to decide how you use them. Drucker argues that effective knowledge workers find our where their time goes, cut everything that’s not productive, and consolidate time into large blocks where real work can be done. If you don’t manage your time, you’ll be swamped by ever increasing demands on your attention and interruptions. And you won’t accomplish much of anything.

I’ve done quite a bit of work in this area.

Time tracking at work

We use Jira to manage our stories and we record our time in Toggl. I track every minute of my day to a task in Jira, specific meeting, or phone call. Every two weeks we run a script to analyze where we spent our time. Then during our retrospective meeting we investigate anything that’s suspicious and do what we can to eliminate time wasters.

Meetings

Meetings are always a huge danger area. I’ve tried various strategies to keep things on track. When it’s my meeting, it’s pretty easy to keep things progressing. But if I’m in someone else’s meeting it’s a little more difficult to create a sense of urgency without taking over.

The best way I’ve found to create a sense of urgency is to have a prioritized list of things we are trying to accomplish and talk about it all the time, both in and out of meetings. During meetings I say stuff like, “Let’s get through this meeting quickly so we can get back working on [our highest priority task]”. If we stray to a topic that’s not on the list or is on the list but we won’t get to it for a while, it’s easy for me to say, “Let’s defer this discussion until it get closer to the top of the list.” It works.

My wife is invited to attend lots of meetings with her work. They got so out of control that she now refuses to attend any meetings without a written agenda distributed in advance. Smart.

Working from home – the ultimate productivity hack

By working from home I’m able to avoid a lot of the interruptions that eat into most people’s days. I attend scheduled meetings and daily stand-ups by Skype and generally have two large uninterrupted blocks of time each day. People mostly communicate with me asynchronously (email, Jira, BitBucket, etc.). I also avoid commuting, which saves me 40 minutes per day over the average person. Here’s a Ted talk with some research results on the benefits of working from home: https://youtu.be/oiUyyZPIHyY.

If you think working from home might help you be more productive, you might suggest it to your boss as an experiment where you just try it for one or two days a week and see how it goes.

Email

Ugggghhh. I struggle with this one. The habit I’m trying to form is to reply by phone if that would be faster than writing an email. My time tracking showed that, like most people, I spent a lot of time on email. I’d write these detailed responses and re-read them and edit them to make them complete and correct. And before I knew it I wrote a little essay and 45 minutes of my life were gone. On the other hand, I use writing as a way of thinking. By writing something down I really get to know what I think about it. I’m getting better but I still catch myself writing when I should pick up the phone.

Avoiding interruptions

If too many people are popping by your office and making you lose your flow, I have two things you can try. First, lots of people wear ear phones as a signal to others not to disturb them. They also help block ambient noise, which helps me focus.

The other thing I recommend is a stoplight system. Tape a folder to your door and place a red, yellow, and green sheet of paper in the folder. Cut the folder so the paper is visible. Set it to red when you are doing something critical and you don’t want to be interrupted unless it’s an emergency. Set it to yellow if you are working on things that require concentration but aren’t so important that an interruption will cost you a bunch of time. When it’s yellow, your coworkers are invited to stop by to talk about work concerns but not to visit. And set it go green when people are welcome to visit (socializing is an important part of being on a team). Green might be good for times when you are answering emails or doing research.

It’s pretty easy to sell the stop light system to people. Just say that you’re running an experiment to see if you can increase your productivity and that you’d appreciate your co-workers’ cooperation. If your experiment is successful, you can make it permanent.

Automate things

Because we are computer programmers, we can automate things. And we should automate things if we’re sure they will payback in a reasonable amount of time.

In my experience we don’t think through these little automation projects to the same level as “official” Jira tasks. And that leads us to make optimistic estimates of how long they will take and the benefits we’ll get from any particular automation project. XKCD has two excellent comics related to this: one is on automation and the other is on the payback from making tasks more efficient. If you carefully choose things to automate, you’ll be okay. If you automate blindly, you’ll waste a bunch of time.

Never let up

You must make time management one of your ongoing concerns. The moment you stop paying attention to where your time goes waste will start creeping into your calendar and your effectiveness will suffer.

Conclusion

I once read that the average computer programmer writes about two million lines of code over the course of his career. Someone picked that number out of their ass but it really stuck with me anyway. Whenever I encounter something stupid or when someone suggests a feature that doesn’t really matter to our customers or our company I think about how this is going to burn x lines of code from my finite limit. And that motivates me to fight to not waste time writing code that doesn’t matter.

If you really want to light a fire under your ass about how finite your time is, check out Your Life Visualized in Weeks. Your career will go by in the blink of an eye–don’t waste a second.

Leave a Reply