Building the personal development plan 4

Building the Scorecard

This should be our last installment of building out the personal development plan.  In our last blog we ended up with the outline of a scorecard that looked like this:


To finish out our plan we have to fall back on the idea of SMART goals.  SMART goals have been brought up quite a bit in these blogs but, as a reminder, SMART is an acronym for specific, measurable, attainable, relevant and time sensitive.  When building out our CFOs and big rocks we spent a lot of time talking about specificity and relevance.  In this final section we will dive into attainability, time sensitivity and measurability.

Time Sensitivity and Attainability

Nothing spurs urgency like a deadline.  Think about those papers you had to write in school or those times you had to get something done by end of day for a client.  Something magical happens when the urgency lever is pulled.  There is typically a little fear involved but it is productive fear.  That productive fear forces us to focus.  It’s amazing what you can accomplish with purpose and focus.

It’s difficult to hold ourselves accountable for personal growth so we have to employ some tricks to convince our lizard brain that these goals are fight or flight worthy.  This starts with building out deadlines that we have to commit to.  These are goals that we have determined to be big rocks, some of the most important things we want to change in our lives.  That should be worth building some urgency around.

The first thing we need to remember about big rocks is that we are working at the one month goal level.  All big rocks should be accomplished within 30 days.  When we set the deadlines for our big rocks, our end date has to be less than 30 days away.  We also want to have a start date for our big rocks so that we draw out any dependencies between rocks.  If one of our rocks is dependent on another being completed, we need to know how and when those dependencies will work out.


In the example above, all start and end dates have been filled in.  The size column is a t-shirt size estimate of how big we think the big rock is going to be to accomplish.  This is a very loose estimate.  The reason we ask ourselves to estimate is to take a first stab at quantifying how much work this actually is.  This is where we need to pull out the realism glasses and really look if these rocks are attainable within the next 30 days.

If you have a bunch of XLs and larges, your chance of completing these rocks is probably pretty small.  The rule of thumb here is that if you have more than one or two larges, you should probably attempt to slice your rocks into smaller, attainable chunks.  Remember that you will have two more months to complete your three month critical few objectives (CFOs) so you do not need to get all of this done in the first month.

While setting goals, it is always good to reach but they have to be attainable.  If you reach too far, if you get to the finish date and have none of your goals completed, what do you think is going to happen?  Exactly.  You’re going to throw the whole scorecard away as another failed tool.  We want this process to be aspirational but not a pipe dream.  If you pick the right rocks, the results will inspire.  If you chase something that’s not attainable, you’re gonna have a bad time.


“What gets measured gets improved.” – Peter Drucker

Measurement is the secret sauce to the whole system.  To explain why, let’s first talk about a subject near and dear to my heart, quantum physics.  One of the foundations of quantum mechanics is the Heisenberg Uncertainty Principle.  The principle states that there is a fundamental limit to what one can know about a quantum system.  That’s not the interesting part though.  The interesting part is the thought experiment that goes with the Uncertainty Principle.  Ignoring the wave/particle duality of light for a moment, Heisenberg asked us to think about photographing an electron to determine its position.  If we try to photograph an electron, we have to hit it with at least one photon, or light particle.  When we hit it with the photon, we will be imparting energy to that electron causing it to move.  So the very act of measuring the particle’s position changes its position.  Hence the uncertainty.  Another way of saying this:  the act of measurement drives change.  This isn’t some old wives tale or management principle, it’s physics baby.

On a fundamental level, we know measurement drives change.  If you want to lose weight, what do you think would work better?  You do your best to eat better and get exercise when you can, then get on the scale every day and see the results, OR you sign up for Lose It! and measure every calorie you eat and calculate every calorie you burn, then get on the scale?  You got it.  The very act of measuring every calorie you take in changes your interaction with food!  You know, if you’re being honest with yourself, that you will have to enter that 750 calorie bowl of ice cream in to your food log for the day.  Is that really worth it?  You may decide that it is, but now it is a conscious choice that has a discrete cost rather than something that you kind of know is a bad idea.  That changes the whole system.

So that’s what you’re looking for when you are building metrics.  You are looking for measurements that will change your interaction with the system.  This is not always easy and will probably require a little iteration to get right.  One of the questions that is always worth asking when building your metrics is: will this measurement change our behavior in the direction we want to change?


Now it will also turn out that a lot of your big rocks may just end up being tasks, simple to dos.  That’s fine.  To dos are a big part of this but the big rocks that require measurement are typically the ones that will drive the most change.  You need a strong combination of both types of rocks when you are building out the scorecard to make progress on your three month critical few objectives.

Once we set our metric, we need to set our goal for that metric for the week.  If our goal is to lose five pounds in a month we know that we need to lose a little over a pound a week to hit that, not plan on losing all five in the last week.  That is what the OBJ column is for, weekly objective.

We now have our scorecard!  In our next process blog we will discuss how we manage the scorecard on a weekly basis.

About the Biz

The horrors of context switching

We’re all busy.  Being busy is fun.  It sure beats being bored.  But being busy can be very counterproductive if we are constantly flitting from task to task like a hummingbird on Red Bull.  While starting The Odyssey I have been working on starting another business and doing some consulting on the side.  This has put me in a state of regular context switching.  Context switching sucks.

When we’re context switching it becomes very difficult to find a state of flow.  When we can never get in the ‘zone’, working on things like our big rocks becomes almost impossible.  One of the best ways to avoid the costs of context switching is to be aware of them.  With that in mind, I dug up an old blog that I wrote about the perils of context switching and pasted it below.  It dives a little into agile development which isn’t super relevant to personal development but the costs associated with multi-tasking are relevant to everybody.  Enjoy!

Context Switching

Context switching is the bane of productivity. For those of you not familiar with the term: context switching is when one is forced to switch from one topic or work item to the next. This is also known as multi-tasking. Sadly, too many people believe they are excellent multi-taskers. This is nonsense. Nobody is an excellent multi-tasker.

The brain is single threaded. We are not processors that can be running two tasks in parallel. We don’t have the internal CPU for such a job. Every time we switch tasks, we have to rebuild our mental architecture. We have to tear down the thought processes for our current task and replace them with the thought processes for the new task. This takes time when we are working in a vacuum. But when’s the last time you worked in a vacuum? Think about how much more time this takes when we are getting interrupted on a regular basis.

This is the famous chart that Gerry Weinberg put together to illustrate the waste caused by context switching.

If the numbers aren’t working for you in the first chart, that is because several assumptions are being made. The chart below explains those assumptions in a little more detail.

If you don’t find these graphs shocking, you’re not reading them right. If you are working on two projects at one time, then you are losing a full 20% of your productivity. If you are working on 5? 75% of your productivity goes straight in the shitter. To say that another way, when you are working five projects, each project gets 1/20th of your time. Rebuilding your mental architecture each time gets 3/4ths of your time.

That doesn’t apply to me, I’m a great multi-tasker

Oh yeah? If you are such a good multi-tasker do these two simple tasks for me: recite the lyrics of your favorite song and calculate the square root of 2,116. The hitch? You have to do these two tasks at the same time. Start the lyrics now and do not pause. Before you finish those lyrics, come up with the answer to the math problem.

In my personal experiments, one of two things happen here. The person gives up OR they come up with the right answer to the math problem but keep losing their place in the song. Humans are NOT capable of multi-tasking. Unless you are a cyborg or have figured out how to split your brain, please stop claiming that you are a good multi-tasker. My crappy personal experimentation aside, the science is in. You can start here for more info:

There is always some wise-ass at this point that asks the question: if that is true how can I drive and hold a conversation? OR, how can I chew gum and walk at the same time. The answer: habits don’t count. The things that you have done so many times where your lizard brain takes over and the action gets moved to auto pilot don’t rely on higher level thought. We are only talking about those tasks that take higher level thought. Which, hopefully, is most of the tasks you do every day at work.

Interesting sidebar edit: It took me an hour and a half to write 80% of this column. I received a phone call when I was almost done writing that I had to take. It took me another hour and a half to write the final 20%. Context switching in action.

So what do we do about this loss of productivity?

One of my old bosses had a great philosophy: you want to move faster? Do less at one time. This is another way of stating the old maxim that less is more.

Let’s get specific and address one of two primary issues where context switching is a huge killer: software development. We’ll cover the other productivity killing issue, meetings, in the next post.

Cut your WIP (work in progress) ASAP

This is where the less is more rubber hits the road. When it comes to agile, one of the questions we need to be asking ourselves all the time is how much we can cut our work in progress. This questioning is where Kanban can be incredibly effective. Kanban translates to ‘visual signal’ and was pioneered on the floors of Toyota plants back in the fifties. Most people will use Kanban to give the team and folks outside of the team insight on the progress of work. Boards like the one below can be seen in almost every agile shop out there:

Unfortunately, for most teams, that’s where the utilization of Kanban ends. This is a shame. If you end with just the visual representation of the work moving from stage to stage you are missing out on the critical improvements that Kanban can offer you and your team. As you dive deeper you realize that much of the benefit of Kanban comes from identifying and eliminating bottlenecks.

One of the ways to tell if you have bottlenecks is to identify where most of your cards are backing up on your Kanban board. If most of your cards are in your backlog (to do) or sitting in Done, this isn’t much of a problem for your team. If however, most of your cards end up sitting in develop or test for most of the sprint right up until the last day: you’ve got WIP problems.

WIP problems typically fall into two categories: context switching and process problems. These categories have a ton of overlap, so we’ll talk about both together.

Set fixed limits for WIP

In a previous life, one of the teams I worked with had six devs, three QA and a product owner. Our rule for this group was the team could only have six WIP cards that were between the backlog and the done swim lanes.

The reaction to this early on was unexpected. The developers complained that they would be sitting on their hands a lot waiting. Granted, there was some hand sitting but not nearly as much as you would think. Instead, the team gelled better than ever before. A lot of agile teams pay lip service to the idea that no matter the task, the whole team pitches in to move product through the pipeline. So dev will help with QA, QA will help with requirements definition, etc. The sad reality is that these teams almost always get siloed. Developers just work on dev and QA just works on quality.

What happened with our team after instituting very strict WIP limits is that the devs got a lot more involved with the QA process and helped test other developer’s stories. In doing that testing, they gained a much better understanding of how QA was writing test cases. Most QA folks can’t code so QA didn’t implement any stories but the QA team got much more involved in the definition of these stories. Our devs also learned how valuable a good unit test is.

In the end, the numbers told the final story. That team went from an average push rate (work items being pushed at the end of a sprint) of 17% to under 5%. And their overall velocity increased by 10%. What we found was that keeping the whole team focused on a small number of items at one time caused us to move a lot faster. Less is more when you limit context switching.

You will need to play around with what your WIP limits are but err on the side of less work items at first. Even though it may feel like some people are sitting around waiting to work, people generally like to work. Chances are, you will find them helping out with other jobs and understanding the process as a whole a lot better. You will also quickly identify your bottlenecks. For us, the bottleneck was QA. Having developers finish more stories was only backing up the QA machine in the production line. Having dev help out with QA made everyone faster.

Segregate the issues coming in from the field

Another issue that can completely destroy your team’s productivity is adding work items to the sprint after the sprint has started. This is agile 101. Most of you know this and know that most product owners would never dare to add a new work item mid sprint. But what happens when a defect comes in from the field? This issue turns out to be bad enough that the customer is genuinely pissed off and now you have your CEO breathing down your neck.

The most effective way I’ve found to deal with this issue is to build a dev support team. We had a rotating dev support team that was made up of one developer with another on back up. The person on the dev support team was only on that team for two sprints at a time. Then they would move to the backup position. When they were the primary support dev, their only job was to handle issues coming in from the field. When there were no issues coming in from the field, they would fix defects. They were never assigned story work.

This is another great anti-silo approach. This forces all of your developers to become familiar with the entire codebase. It also shows you as a leader, how your different devs react to stress.

What if I’m on a custom software team?

If you’re building custom software for clients, context switching comes with the territory. It can be managed but not eliminated. The most effective custom or outsource teams that I have worked with manage this in a couple of ways. First, they budget for the context switching costs. Most of these teams have been doing this long enough that they understand the impact of context switching WAY better than product development teams so they incorporate it into their estimates. They also mitigate some of the risk by trying to keep their resources on one project and only one project as long as they can. When that is not a possibility, the best outsource teams that I have worked with try to limit their resources to working on only one project per day. It’s easier to rebuild that mental architecture if you only have to do it once per day.


None of us can multi-task effectively which is why context switching is such a killer. Acknowledging that multi-tasking is the problem is the first step in the healing process. The more you can eliminate context switching from your life and the lives of your team, the more productive you will be. This is part one of the context switching topic wherein we covered the mechanics of context switching in the agile product cycle. In the next post we will cover the other big context switching time thief, meetings.


Building the personal development plan 3

Personal Development Big Rocks

In our last discussion on building a plan, we finished with our three month vision.  Here was the example we were using from our last post.


This was built from a combination of our critical few objectives and our overall three month time boxed aspiration to understand who we are.  In the next steps of building our scorecard, we build out the specifics of how we will realize this vision.  This starts with our big rocks.

Big Rocks

I first heard the term big rocks from Dr. Stephen R. Covey as one of the anecdotes he references in 7 Habits of Highly Effective People.  In case you haven’t read the book, or it’s been a while, I’ll sum up the idea here.  Covey asks us to think about our time as a mason jar that slowly gets filled up with all the things that we need to do.  All of the big important things we need to do are represented by big rocks.  We can think of all of the urgent things that come up throughout the day that we have to take care of as smaller rocks or gravel.  Finally, we can think of all the little things that we have to take care of as sand.  The sand items are things like email, text messages, interruptions, Facebook, etc.


Covey posits that the most effective people are those that focus on the big rocks first.  Back to the mason jar analogy, if we put the big rocks in the mason jar first, then we still have room for the urgent stuff (the small rocks) and the not so urgent (the sand).   The point of the analogy is that most people don’t work like this.  Most people tend to focus on the urgent which is not necessarily the important.  If you start filling your mason jar with the gravel and the sand, there’s no room for the big rocks.  When you are focusing on the urgent, those big important things never get done.  These are the big ticket items, the goals that, if completed, could have a big impact on your life.  Big rocks are the tools that allow us to work smarter rather than working harder.  These are the targets that drive purpose, rather than just pass time.

As I explained this analogy to one of the groups I was working with, one of the Sand-People.jpgparticipants claimed that he was nothing but a sand person.  Without missing a beat, one of the other participants said, “the sand people are easily startled, but they will soon be back, and in greater numbers.”  Star Wars hilarity aside, there are some lessons here.  This particular participant is one of the best educated people I have ever met, having both a Ph.D. and a law degree.  He claimed that as a patent attorney, his entire work existence was driven by sand and small rocks, by the urgent.  For him, he feels like it is just one case after another.  He wasn’t alone.  My wife is a doctor and she has felt the same way.  While she is at work, seeing patients, it is all about the urgent.  One patient after another, it becomes difficult to focus on the big stuff.

This is true with a lot of professionals, especially those professionals where he/she is the product.  The services they provide drive the business.  One of the sad realities of the schooling that professionals receive is that it is so specialized.  My wife spent four years in medical school and another three in residency and never once had a single class or lesson on business.  When she opened her practice, she felt constantly overwhelmed.  She had to see 12 to 15 patients a day as a family doc and try to run a business on top of that.  So where can big rocks possibly fit in with all of that urgency?  The answer for her was nowhere.  After about five years of this urgency, like a lot of professionals and certainly like a lot of family docs, she wanted to quit.  She loved the patients and the medicine but hated the system that forced her to practice medicine like a drive through attendant.  She was becoming bitter and that bitterness was making her unhealthy.

It took a couple of years of further unhappiness before she finally was forced into realizing that she would need to make some big changes.  She could either quit and do something else or she could focus on the business and become a business owner and not just the product.  After years as a sand person, she came to a tipping point where the big rock decisions she had to make were forced on her.  After going through that pain, she now splits her time between being a business owner and being a provider.  When she’s a business owner, she is allowed to work on the big rocks that allows her practice to work smarter.  When she’s a provider and back in the sand, things are running far better because the business invested in efficiency.  The sand doesn’t seem nearly as suffocating.

The moral of the story is that the big important stuff has to get done one way or another.  You can either wait until there is an emergency or you can be proactive and enjoy the journey.  If you look with the attitude of – let’s catch this before it turns into a fire drill – you will find that there is always time for the big things that drive improvement.  Big rocks create opportunity.  Sometimes that opportunity comes in the form of efficiency.  Efficiency creates time.  Sometimes big rocks create happiness, sometimes they create better relationships and sometimes they create mastery.  Regardless of the big rocks that you choose, they are going to affect change that will impact your life for the better.  The only mistake we can make when focusing on big rocks is not spending time on them.

Big Rock Process

Back to the process.  Once we have our critical few objectives, we need to figure out what we can do in the short term to accomplish our three month critical few objectives.  When we build out our big rocks we are now working at the one month level.  These big rocks are the important things that you can get done in the next thirty days that will move your three month objective forward.

Each big rock needs to fit the SMART goal definition.  This means that it needs to be Specific, Measurable, Attainable, Results oriented and Time boxed.  When setting goals, most people go wrong at this stage.  The two big mistakes I see all the time is that folks will either try to boil the ocean and go waaaay too big or they pick something that is too ambiguous, where you can’t tell if you’ve succeeded or not.

Here is an example of some big rocks built for the vision above:


It’s ok to lean on the obstacle and plans from the WOOP step as a reminder of what you are nervous about in hitting your targets.  The obstacle and plan become far more important in our next step however, when building out our metrics.

Now that we have our big rocks filled out, we are making some serious progress on the end scorecard.  Here’s how the scorecard is starting to look:


In our next process post we will discuss how we are going to measure for success and how we set our time boxes on each big rock.


Building the personal development plan 2

The personal development plan

When we last wrote about building the personal development plan, we ended with building out the four skills and passions that we wanted to focus on over the next three months.  These skills recognized the character strengths necessary to improve or create these skillsets.

The finale of that step looked something like this:


When building these skills out with some of the groups we’ve worked with, the number one piece of feedback we received was that it is difficult to come up with skills and passions that you want to improve when they are not related to problems being faced in the day to day.  Utilizing that feedback, our next sessions will prime the pump before we start deciding on skills.  We will do this by asking our users to first think of those things in the last couple of months where they fell short on something, they felt scared, or they were disappointed in their own performance.  We will be asking them to do this in all four life categories of Work, Health, Play and Love.  Once these issues have been identified we will then ask our users to build out the skills and passions that would have changed these outcomes for the better.


Once the skills and passions have been identified, we then move on to how we are going to act on them.  In a previous post we discussed the benefits of WOOP.  This is a great tool for crystallizing goals.  Once we have identified the problem space and the skills and strengths necessary to overcome those problems, we focus on specifics.  This is where WOOP becomes the go to tool.

The first step of WOOP is the Wish element.  We spend a couple minutes thinking about the most important goal we wish to accomplish in the next three months related to the particular skill or problem set.  Once we have this written down, we focus on outcome.  Outcome forces us to ask: if your wish were fulfilled, what would be the best possible outcome?  How would that outcome make you feel?

Some of ours users struggled with understanding the difference between wish and outcome.  Most of our test group seemed to think it was the same thing.  The difference between the two steps is that the wish is defining what you want to accomplish and the outcome is taking the step of visualizing the positive outcome.  Most of our users believed that they were doing that anyway in the wish step so felt the outcome step was redundant.  To each their own.  We are going to keep both steps because we believe that reinforcing the visualization of success is really powerful.  Not all users will do that in the wish step and we want to make sure that we explicitly call this out.

Once the Wish and the outcome steps have taken place, we end up with something like this:


In the next step we explore our obstacles.  This is where we spend some time trying to understand what is going to prevent us from hitting our goal.  The trick is to be specific.  There are a lot of obstacles that we don’t have any control over.  So we need to hone our focus by asking: what is your main inner obstacle?  What within you is holding you back from accomplishing this wish?  This is a critical step in pulling ourselves out of the victim mindset.  In this step, we are acknowledging that our biggest challenges come from within.

Once we identify the obstacle, we work on the plan.  This is a traditional If..then statement.  If we hit this obstacle then we take this action.  The question we ask: what can you do to overcome this obstacle?  What action can you take when it arises?  This plan gives us the power to do something about the obstacles we know we will run into.

Here’s an example of this phase:


This was just the first of four WOOPs.  Once all four WOOPs are completed, we then move on to building our vision.

Critical Few Objectives (CFOs)

The critical few objectives concept comes from the balanced scorecard discipline.  These objectives are critical because they are our top priorities for the three month period.  If we complete them, they will have a changing impact on our lives.  They are few because our only chance at success is if we keep focus.  The whole thing only works if we pick a small number of achievable goals.  We set the max here at four.  Finally the objective is the SMART goal that comes out of the WOOP Process.

As an aside, we did receive some feedback that we are using way too many acronyms.  Guilty as charged.  This all comes from a biz background where the landscape is littered with these capitalized eyesores.  We will be working to personalize our terms as we build the software.

To build each of our CFOs, we ask our participants to come up with some combination of wish and outcome to create the CFO.  This is primarily a wordsmithing task at this stage.  Here’s an example of two CFOs:


The three month vision

Once all the CFOs are created, they fit nicely into a vision statement.  The vision statement becomes the north star for the next three months.  The beginning and end of the vision statement are boilerplate for the first plan.  Moving forward these become custom tailored as our users get closer to defining their own purpose.  Here is an example of a vision statement.


The vision becomes the keystone for building out the rest of the scorecard.  Stay tuned as we’ll cover that in our next process blog!