Reno, NV    +1 (800)0 621-0871

Go back


Always Be Delivering – Time Management Tips for Software Developers from Sales

  |  May 19, 2014

Ten years ago, I “took a break” from software development and picked up some time management tips for software developers from an unexpected place. After getting laid off from a failing startup (see story below) and travelling abroad, I pursued opportunities in real estate sales as well as home remodelling and construction.

In the course of obtaining my real estate license and going to work for a broker, I received some sales training from Coldwell Banker. One of the things I remember taking away from this was the way a sales person has to manage their time. Real estate sales people often enjoy a great deal of autonomy — similar to many software developers, especially freelancers but also many employees. Often salespeople are free to plan their day, generate and pursue leads, and of course close deals. No one dictates their schedule but they do receive calls and interruptions and perhaps, partake of office camaraderie and life in general while juggling various activities and tasks to generate business.

A software developer generally enjoys large blocks of time to structure as they see fit — to “do their thing.” They often confront a variety of interruptions and sometimes emergencies, which they must juggle with actual development, research and other related activities.

At the beginning, when you are starting out in sales and don’t really have the hang of it, you are staring at an empty calendar and no leads. What do you do? Say by some luck, business comes your way. Now you have a lot of work to do. You feel good because you are busy. But are you doing all the things you are supposed to do? Once you have concluded the business in front of you, you may invent or discover other tasks, but how do you prioritize effectively?

We were taught to divide or classify our activities into three categories:

  • “A time” – Working with a client or lead toward closing a sale.
  • “B time” – Working to generate leads, proactively through marketing and outreach.
  • “C time” – Everything else.

We were supposed to look at how we actually spent time and maximize the “A” time, followed by the “B time” and to minimize the “C time.”

“C time” has a way of creeping into your schedule and proliferating. It can quickly take over. After a couple months of not enough A or B time, your lead book is empty and it’s been weeks or months since your last commission check. Things look bleak.

This is also the lesson delivered so memorably by Alec Baldwin in the iconic scene from Glengarry Glenn Ross. 


Blake (Alec Baldwin) delivers time management tips for software developers, ahem, salespeople…

“ABC — Always Be Closing” is an even shorter mnemonic for this.

After completing my book, Secrets of the ÆLOGICIANS, which includes a chapter on maximizing (Developer) productivity, I focused on sales and marketing for ÆLOGICA. Naturally, I revisited my sales training from long ago and while managing my time accordingly, it occurred to me that there might be some analogy we can draw here for software developers.

The primary responsibility of the professional software developer is to deliver value in the form of working software that does something valuable for someone. This can be shortened to the idea of “Delivering Value.” So we might say, “Always Be Delivering,” or “ABD.”

Let’s use this as a starting point to classify our software development time into categories “A”, “B”, and “C.”

We will call “Delivering Value” the “A time” of our software development activity. Delivering means different things but it usually can be taken to mean shepherding valuable features into production. Every environment is different but we always have some tasks to do in addition to “just writing code” in order to get that code into production. Too much ceremony or bureaucracy causes the pace of value to delivery to drop and we must be on guard against it but for now, it all counts as “A time”.

The analogous “B time” for a developer consists of activities which will lead to delivering value, such as:

  • clarifying requirements
  • reviewing another’s code
  • otherwise helping another developer to deliver value
  • improving the deployment process
  • automating chores
  • optimizing your environment

“C time” is everything else:

  • meetings not related to delivering value or planning to deliver value
  • email not related to “A” or “B” time activities
  • office chit chat
  • long lunches and breaks
  • IT responsibilities unrelated to development
  • tweaking your environment in ways not related to productivity
  • watching screencasts and conducting research into unrelated topics
  • surfing hacker news

So when you sit down at your desk and a block of time from as short as 20 minutes to as long as 3 hours stretches out before you, what do you do?

Ask yourself, do I have any “A time” tasks? Can I deliver something or move something closer to delivery? If the answer is “Yes,” do that. If the answer is “No,” start down the list. See if you can get clarity on requirements to be able to deliver something. See if you can review someone else’s code so they can deliver something. Then if you have exhausted those potential worthy uses of time, try improving your deployment process or automating some time consuming chore.

If you consistently put these “A-time” and “B-time” activities before the “C time” activities, you will experience a boost in productivity. It seems obvious but sometimes a little mnemonic helps us to stay on track: ABD – Always Be Delivering (value).


For those interested in my personal story here is how I came to “take some time off” and explore opportunities in something as wildly different as real estate sales:


I felt burnt out after delivering what I thought was my best work to date for a doomed startup. The company had undergone a slow retrenching after an acquisition by an even more doomed but cash-rich startup, led by a superstar CEO who didn’t really need another turn at-bat.

We lacked committed, strategic leadership and the founders and executives who built the only profitable part of the original company I started with had all been let go. I was the sole person who remained from the beginning and I had been assigned a new manager who seemed not to like the cut of my jib. I was still a bit rebellious, inclined to follow my own schedule and desiring both autonomy and responsibility above my pay grade. When I walked into his office to proudly tell him my component of the system was done and committed to the source repo, he said “Sit down, Steve, and close the door. We need to talk.”

I saw the look on his face and knew what was coming. He was a little smug because I think he was getting to do what he wanted to do for some time — lay me off. At the same time, he was uncomfortable because deep down, I think he knew that if they were letting me go, he would be next. He was of course. They let him go within a week or two as well. The CEO who decided to pull the plug had basically given him the dirty work of wrapping things up.

In the aftermath of that episode, I took some time to travel abroad and consider my future. I sailed down the coast of Spain, spent a month in Ibiza, and wandered around southern Spain and Morocco. I knew I wanted to take a break from software and startups. Eventually my funds ran low and I looked around for other things I could do to generate income and help my family in a personally fulfilling way.

It turned out that the most immediate need was to help my father with a real estate transaction and also my mother with her own real estate business. Being divorced, they could not work together so they both needed my help in their own way. Real estate was heating up at that time and I decided to get a real estate salespersons’ license and see what I could do to learn some different skills and help out where I could.

This led to helping a friend in a remodelling business and eventually to starting a company to help real estate agents sell new construction, which in turn led me back into software development and eventually to discovering Ruby on Rails which rekindled my passion for the craft. The rest as they say, is history.

The lesson here is that feeling burnt out is normal. It happens. Sometimes you need to change what you’re working on, sometimes you need to change who you work with, sometimes you need to change your tool set or platform, whatever it is — that feeling of “I don’t know if I am cut out for this anymore” is common and shouldn’t make you contemplate the end of your career with such fatalism. Also, experience outside in a family business or another line of work often can help make you a better developer in unexpected ways.