In my last post I described the power of seeing your whole company as a single system and using the Theory of Constraints to zero in on the area that is most likely to benefit from improvement and focus your efforts there. This should be your ultimate goal. But you likely need new skills and practice with thinking in systems before you can operate at this level. So, in this post, I’m going to show you how to use the Theory of Constraints on yourself to increase your effectiveness.

But, first, what is effectiveness?

From BusinessDictionary.com:

The degree to which objectives are achieved and the extent to which targeted problems are solved. In contrast to efficiency, effectiveness is determined without reference to costs and, whereas efficiency means “doing the thing right,” effectiveness means “doing the right thing.”

In business, there are only two objectives when you get right down to it:

  • increase revenue
  • reduce costs

Unless you are doing one of these two things, you’re not being effective. And, obviously, you should prefer to work on things that have the biggest impact on revenue or costs.

Here are some examples of ineffectiveness I’ve encountered:

  • making detailed plans for tasks you won’t actually work on for months, if ever
  • complaining
  • choosing to work on urgent but unimportant tasks
  • excessive preoccupation with finding and using the best tools (in the long term good tools are important but at some point your tools are good enough and the hours or days you spend finding, configuring, deploying, and learning how to use the latest and greatest tools is time you didn’t spend increasing revenue or reducing costs)
  • researching ‘cool’ technologies with no practical applications in your business
  • ‘gold plating’ – adding features or polish to the project past the point of adding value

If you ever catch yourself saying ‘it would be cool if we…’, I encourage you to stop talking and ask yourself if you are being effective or gold plating.

Let’s do and example

Okay, I want you to consider yourself a one-person business. You sell software development services to your current employer. Your inputs are your time, a Jira story, and the clock cycles on your computer. And your output is code that satisfies the requirements of the Jira story. To keep things simple, I’m going to assume that you are the only programmer on the project.

You’ve got a very simple system here and it’s a perfect test bed for experimenting with the Theory of Constraints.

Let’s increase your effectiveness using the five focusing steps

Let’s start with the fact that your system has a constraint. If your system didn’t have a constraint, you would have infinite productivity.

Possible constraints

I’ve made a list of some possible constraints for you. Does anything jump out?

  • you aren’t really an expert with the language used in this project so you have to go slow and look up lots of commands and syntax
  • you sometimes code yourself into a corner and have to start over
  • your development vm keeps getting corrupted and you have to restore from a backup every couple of days
  • you’ve boss instructed you to work from the top of your backlog but it doesn’t seem to be in any particular order
  • you think you’ve solved the problem but your code keeps breaking things in production so you have to keep going over the same code over and over again until the bug reports dry up
  • you frequently get interrupted and have a hard time concentrating
  • the specs are often unclear and incomplete and you have to seek clarification from your supervisor. It often takes him a day or two to get back to you
  • your supervisor is against automated testing and forbids it’s use so you have to do all your testing manually
  • the existing code doesn’t appear to have any organization or structure. There is a mix of procedural, object oriented, and functional code in the project. The naming is all over the place.  3,000 line files with 1,000 line methods are common

Step 1: Identify the system constraint

Where is the constraint? Is it internal or external? Is it physical or a policy? Seriously, stop reading and pick something.

If this was a real situation, I would create a “current reality tree” and figure things out. There are multiple things going on here that are slowing you down and a “current reality tree” will help you sort it out. However, this is just an example so I’m going to take a shortcut and tell you where I think the constraint is and see if you agree with me.

Based on my experience, the current constraint is the unprioritized backlog. In real life, I’ve got a backlog with hundreds of stories in it and most of them will never get done. There just isn’t enough time to fix everything defect and add every feature our users have requested. So if you’re working from an unpriortized backlog, you are probably doing a lot of low value work. Yes, it sucks that you have so many roadblocks slowing you down but they don’t matter if you’re not doing anything important. Do you agree? Remember, 10x programmers deliver as much value as they can.

Step 2: Decide how to exploit the constraint

Prioritize your backlog. Your boss should probably be involved too but if your boss is as busy as my boss, he’s probably not going to be very available. My strategy is to get the top few stories or epics to the top of the backlog and then let my boss choose the next three priorities or suggest something that’s most important to him that didn’t make my list. That usually works well.

You might need to educate your boss on the value of a prioritized backlog (I’ll cover the best ways to do this in another post). For the purposes of this example let’s assume your boss was agreeable and you’ve prioritized your backlog.

Step 3: Subordinate everything else

If you’ve prioritized the top few stories in your backlog and you are only working on those stories, you’ve probably given yourself a 3x or 4x boost in effectiveness right off the bat. But in this step you need to ensure your constraint is always as optimized as possible. So maybe you take an hour or two a week to go through the backlog and update your priorities. You choose to do less coding in this step to ensure that the top of your backlog is very well prioritized.

This point is important so I want to emphasize it. You intentionally reduce the amount of code you produce so you can maximize your overall effectiveness.

Step 4: Elevate the constraint

If you’ve solved your constraint then you skip this step. If not, need to figure out what to do to ensure you are working from a prioritized backlog.

This is the step where you can make big changes but only if you can’t overcome your constraint any other way. Don’t take this step lightly. You can do a lot of damage to your effectiveness if you get this wrong.  Maybe you need:

  • new project management software
  • to hire a dedicated project manager
  • more meetings with the users of your software to determine their priorities

Step 5: Go back to step 1 but beware of ‘inertia’

Loop back to step 1 and determine your current constraint. Is it still your backlog or has your constraint moved elsewhere in the system? Whatever the case, if you keep working on your constraint, your effectiveness will soar!

Wrapping up

This is a simple example of the power of applying the Theory of Constraints to yourself to improve your individual effectiveness. While a crashing vm is annoying, it’s only costing you a couple of hours a week in lost productivity (2/40 hours = 5%). That’s nothing compared to wasting your whole week working on inconsequential tasks (40/40 hours = 100%).

In my next post I’m going to show you how to start looking for the constraint in your company. Stay tuned.