Grit Many people have talked about Angela Duckworth and her book, Grit: the power of passion and perseverance. As I have yet to read the book, I was happy to get a note from a friend with a high-level summary from Inc. Magazine, 11 Signs You Have the Grit You Need to Succeed

Grit is that "extra something" that separates the most successful people from the rest. It's the passion, perseverance, and stamina that we must channel to stick with our dreams until they become a reality.

And the 11 signs are (with more detail at the article - and likely in the book):

  1. You have to make mistakes, look like an idiot, and try again, without even flinching.
  2. You have to fight when you already feel defeated.
  3. You have to make the calls you're afraid to make.
  4. You have to keep your emotions in check.
  5. You have to trust your gut.
  6. You have to give more than you get in return.
  7. You have to lead when no one else follows.
  8. You have to meet deadlines that are unreasonable and deliver results that exceed expectations.
  9. You have to focus on the details even when it makes your mind numb. 
  10. You have to be kind to people who have been rude to you.
  11. You have to be accountable for your actions, no matter what.

The funny thing when I look through this list and see some of the opposites in my own personality, I wonder "now what?"  Does this mean I am not gritty enough?  No, I think the idea is to point in a direction that will create more of this characteristic.

[Photo: "Grit" by KylaBorg]

The Wall Street Journal has a piece on How to Revitalize U.S. Manufacturing.  Unfortunately, it is centered entirely around governmental policies and regulation to shift more and more manufacturing* to be done domestically, instead of importing goods from elsewhere.  (This same applies to any country or region concerned about their manufacturing base.) 

Why do companies shift manufacturing to other locales?  As the article acknowledges, the biggest factor has to do with cost - often the cost-per-part, instead of the total cost (additional shipping costs, additional inventory costs, etc.)  

But why? Why can't manufacturers in the U.S. produce goods more effectively, so that the cost logic doesn't force their hand? We have plenty of intelligent people who have studied industrial engineering or who use Theory of Constraints and Lean and other approaches.  We must be able to produce the same goods with the same raw materials - so the cost equation has to relate to the overall operating expenses and inventory required to make that happen.  

* The article focuses on manufacturing, but I see the same logic used when off-shoring services too.

End of the month syndrome is unfortunately familiar common in manufacturing businesses: a large portion of the monthly shipments happen in the final days of the month.  It's not because customers don't want the products earlier, but because they are driven by competing needs.  On the one hand, they want to keep costs under control which might mean less overtime and lower pressure to get products out the door.  But then there is also the need to meet customer needs and meet the demands of business to show consistent bookings each month (we don't get paid until we ship).  This often drives a different set of behaviors - do whatever it takes, including overtime or other "expensive" measures.   Similar effects happen in supply chain and retail -- often driven by similar thinking (discounts to drive unit sales, even though they don't drive profit).

Of course this kind of thing can happen on other cycles: end-of-quarter or even end-of-year.  Here is a great example of this phenomenon from today's Wall Street Journal: Airbus Tackles Its Procrastination Problem: says

Plane maker had to work round-the-clock the past two Decembers to meet yearly jet-delivery targets

Reading the article further, it isn't just the last two Decembers - it has been several years where they've had to significantly push production in the last year of the month to hit the numbers.  And even more evidence of the syndrome is that production is much lower in January and the first quarter of the year than towards the end of the year.  The article also makes it clear that there is a business need to be more predictable: shipping consistently each month, rather than the big ramp at the end of the year.  

How to overcome the problem?  The general direction is to find a solution that allows companies to meet the needs of spending wisely AND shipping on time.  

Reading Tuesday's Wall Street Journal, the opening to the article The Real Fear Is When We All Fear Alike caught my eye.

It isn’t what you worry about that hurts.... It is what you know for sure.

There is a set of principles in Theory of Constraints that come from Eli Goldratt's last writings on the idea of having a "full and meaningful life".  These are the Four Pillars of TOC: core beliefs embedded within much of the way Eli Goldratt - and anyone involved in TOC - approach the world.

  1. Inherent simplicity: Reality is simple and harmonious.
  2. Every conflict can be removed: Don't accept conflicts as given.
  3. People are good: Avoid blaming. There is always a Win-Win.
  4. Never say, "I know": Every situation can be substantially improved

And that last element is what caught my eye in the WSJ. The author was talking about financial markets and the assumptions that investors make about the way markets are behaving.  If everyone believes one thing but discovers a different reality, it often causes major disruptions in markets.  

But the same thing happens in business, families, or just about anywhere else.  If "I know" something, I am not inclined to check for holes in my logic.  I'm not inclined to think a situation could change.  I'm inclined to think past performance WILL be an indicator of future performance.  I block myself - we block ourselves collectively - to thinking and seeing different ways of doing things.

Graham drinking "coffee" The people at Personal Kanban posted an article that referenced "coffee" that has been sitting in my queue, waiting for an opportune moment to comment.

However, being a personal effectiveness aficionado, it isn't about how much fun one gets from coffee.  It's the reason that many people claim to drink coffee -- to get that boost from the caffeine.  But, really, in most work these days, are people dragging mid-day because they don't have enough caffeine?  Or are they dragging because it isn't clear what they are supposed to be doing?  

If you find yourself dragging, and the coffee is merely a delicious distraction, maybe the problem is a little more interesting: lack of clarity!

Clarity > Coffee

Studies show anxiety diminishes and success rates soar when abstract goals - the very nature of knowledge work - are clarified, when they are transformed into concrete and attainable steps. Such is the case when we visualize work on a Personal Kanban. Especially for knowledge workers, getting all those amorphous tasks out of your head and easily visualized on a board demystifies your priorities, your tradeoffs, and makes work manageable. 

What is more motivating, being told "go do this", or understanding that "this" will bring some new value to the organization?  Or simply that "this" has a clear connection to the bigger needs of the organization?

So, sit back (with your coffee), and try to figure out why you are doing what you are doing, not just what/how.  I find this is a much better motivation, than my mother's old chestnut, "because I said so."

[Photo credit: That's my boy!]

Camping 08

People like to be busy.  It seems like it is built into our DNA.  A recent post from Joitske Hulseboch has me thinking about this again, Busy is the new smoking and she links to an earlier post with some advice, Only suckers are busy (in Dutch - thank you Google translation) by Annemiek Leclaire.

There is a strong need in our culture to "contribute."  For many people, this gets translated into doing something.  And for people who manage other people, this gets translated into some version of "if you aren't busy, I can give you something to keep you busy."  And many organizations have a real or implied threat: if you aren't busy, you are likely to be outsourced / fired / made redundant.  And what are you supposed to do instead of "be busy"? Sit around and "do nothing" while waiting for that key piece of information, or that key activity to start?

This sounds like a classic internal conflict: On the one hand, find things to do in order to always appear to be contributing (and keep your job).  On the other had, be available and ready in order to support the bigger picture in your organization.  People have a strong tendency to fall towards the "keep busy" side of things because of those underlying assumptions about job security.  And surely, doing something has to be better than doing nothing.

However, one of the side effects of the "keep busy" side of this is that it means people are not available when they are really needed to contribute to a key activity.  Particularly in the context of knowledge work, it is very difficult for people around you to know whether you are engaged in a key business activity, or if you are doing something of lower priority to fill time - like writing a blog post.  And if people aren't available for a key activity, that key activity ends up takes longer due to all the waiting.  And the waiting and restarting and then waiting again for someone else often generates errors or mistakes and rework.  All of this ends up extending the overall effort by massive amounts.

Improvement programs that focus on fixing the work process - optimizing the activities themselves - often don't create that much of an overall improvement because they miss the time lost due to flubbed handoffs, waiting, and rework. This time is significant - on the order of 25% or more of the duration of a project.

The improvements that have a lot of success here tend to emphasize getting the work out in the open: shared workspaces, visual boards, kanban, etc.  These create a collective understanding of the work and what needs to be done on a regular basis.  I find the exercise of learning what people are really doing to be instructive: often even the managers don't have a good picture of everything that people are doing.  Even for solo contributors or self-employed consultants, having that visual display of what is happening can be helpful in prioritizing and getting "busy" on the right things. 

An analogy:  We often operate as if we have a large lake to swim in: many places to go and things to do.  But in reality, in any kind of project, we are rowing down a river to meet an objective.  The group must row in the same direction and seek to remove barriers as they arise, or the project doesn't get done.  Activities required will present themselves as the river flows - there will be times of intensity and times of calm.  Of course, the analogy breaks down because those times of intensity will be different, depending on the participants' roles.  

[Photo: "stream at Lake Dennison" by Jack Vinson - me!]

I see a lot of projects within business support organizations that look like "implement this tool."  And then the organization is surprised when the project takes much longer than expected and the tool doesn't get used to the extent expected.  

This shouldn't be a surprise. The organization is often focused on the tool, rather than the larger purpose and how the work gets done.

This comes up nicely in an article from Davide "Folletto" Casali, The Three Speeds of Collaboration: Tool Selection and Culture Fit:

Choosing the right tool is a weird thing to do, because it’s at the same time the most important choice and the least important choice you can do. It’s a paradox because without a tool you can’t collaborate – and mind that: a tool isn’t necessarily a software tool – but at the same time if you have clear what you are trying to do you might find yourself choosing something that isn’t even software, or isn’t even specific for collaboration.

The article focuses on collaboration tools, but remove the collaboration concepts and apply your favorite job that software should do. The idea still make sense.  The tools have to fit with the way the organization works - both the formal and informal processes for getting things done.  Has the tool been constructed with assumptions that fit with the way things are done in your organization?

I still go back to the Theory of Constraints "questions for technology" related to this conversation. ("Technology" doesn't just mean software, it could be anything new and different - like putting bigger wheels on a mountain bike.)  The questions go along the lines of this:

  1. What is the power of the new technology? 
    What's the big idea? Why is it so great? But also, where is it expected to fit? Where doesn't it fit? Related to the Casali article, what are the assumptions behind the technology?
  2. What current limitation or barrier (that exists today) does the new technology eliminate or vastly reduce? 
    This is a classic TOC phrase, but the idea: What problem does it solve? How would the value proposition of the organization change if that problem were to go away?
  3. What policies, norms and behavior patterns are used today to bypass the limitation?
    The limitation is there.  What do we do because of it? What policies, practices, structures are in place because of the limitation?   
  4. What policies, norms and behavior patterns should be used once the new technology is in place?
    Using new technology in the "old way" will likely not unlock the full value of the technology. If the limitation goes away, wouldn't many of the behaviors and policies no longer apply?  Do we still need to do monthly financial close if we have real-time data in our financial systems?
  5. In view of the above, what changes/additions to the new technology should be introduced?
    I love this question. Now that we understand the situation into which this the technology is applied, what must be added/changed/removed to make it even better? This could be core in the technology, or it could be something about how it is applied to the problem at hand.
  6. How to cause the change?
    How to fit the new technology into the overall organization?

The Questions for Technology are nicely discussed by Eli Schragenheim in this video conversation with Christian Hohmann from last year.  Schragenheim was involved in the original development of the questions for technology in the book Necessary but not Sufficient (my latest review).

Innovation thinkingI received a review copy of Osama A Hashmi's upcoming book, Innovation Thinking Methods for the Modern Entrepreneur.  Subtitle: Disciplines of thought that can help you rethink industries and unlock 10x better solutions.  It is to be released on 23 March 2016.

It's a short book, meant to be a quick read and guide to start thinking about thinking.  Or maybe, more accurately, to get people doing something differently about thinking.  (And do so while drinking coffee - a frequent side joke throughout the book.  It's hard to fault a guy who likes coffee so much.)  The tone is light, but insistent - new ideas don't come about with the kind of thinking that got us where we are now, to paraphrase Einstein.

What is "innovation thinking?"  It's in the subtitle and first chapter - creating 10x better solutions.  In my mind it is ways of thinking that challenge the status quo. Challenge the assumption that small tweaks are all that you can do.  Challenge the belief that the problem is already "solved" or maybe that it "can't be solved."  He also explicitly talks about Innovation Thinking as different from incremental improvements and small changes that have become de rigueur in the startup community (i.e. Lean Startup).*

Hashmi uses the book to describe 20 innovation thinking methods - briefly introducing each of them and then providing some examples. The methods ranging from adopting different mindsets and points of view, to framing sentences and techniques, to concepts borrowed from other disciplines. Most of the examples draw from the technology world where Hashmi works, though the methods apply to any industry.

A number of the methods resonated deeply for me in connection with the work I do in Theory of Constraints, particularly the Thinking Processes.  The surface of many problems are just the visible symptoms of an underlying system(s).  That system consists of many things - the physical world, the policies and practices of the industry, the history of what came before, etc.  As I read the book, it struck me that many of the thinking methods seek to understand the system at a deeper level.  Changes at the deeper level of the system will have much more significant impact - and are often harder for others to replicate, particularly if they have built themselves into the existing system.  I liked how these methods give additional means for digging deeper or trying to understand how the system generates the current effects. 

Hashmi doesn't spend time describing the theory or diving into the supporting research for the various thinking methods - this is both an advantage and disadvantage of the book.  The advantage is that it keeps the book short and fast, and helps Hashmi maintain his conversational tone throughout.  The reader can pick as many or as few of the methods as they want to try them or explore further.  The disadvantage for a curious guy like me is that I want to track down those references.  Over some coffee, of course.

* Hashmi tries to walk a line here.  Lean (and other) methods are not wrong - they can be quite beneficial in the right settings - it's just that in the context of "innovative thinking" the way these methods are employed do not create 10x changes.  And of course I have to say that it really depends on how people apply any of these approaches to thinking.  Theory of Constraints and Lean can be used to help people think very differently about their world and their situations to create very different results.  I also agree if the goal is incremental improvement, that is all one will get, no matter how they are thinking.  

The past is a foreign country, they do things differently there. - L. P. Hartley, The Go-Between, 1953.

I ran across this quote in a podcast talking about how an historical event still has repercussions today.  But the thing that rang for me is related to another book I have been reading about the way we think about the world.  In our minds, we tend to think things are very much like they are today -- that the way we do things and the way we think about things now is the same as it was 5, 10, 100 years ago.  But it is not the case.  The world changes. Technology changes.  

Think of all familiar practices and policies - written and unwritten - that govern the way we operate.  All those things that people say, "That's the way it has always been" are only true because they don't know (or don't remember) what it was before.  Does it need to always be that way?

If we can understand some of the reasoning behind these things, we can ask whether those policies or practices should still be in place.

Why?  Because those policies and practices often block improvements.  Your classic claim that "people resist change" often comes from these hidden beliefs about the world -- on both sides.

Put on a different hat, and think about how things are different in the past. What was the currency, the language?  This can help see why these practices and policies came about.

RollingrocksI have been following Clarke Ching's efforts to write Rolling Rocks Downhill over the years, including reading one or two early versions.  But somehow the final published version felt very different from the earlier versions.  One thing that hasn't changed - I could hear him in the voice of the main character I read the book to myself.  I've noticed the same thing when I've read other books by people I know in real life.  

In some sense, the book is a classic business novel in the Theory of Constraints vein: the main character (Steve) has a major problem: the software project that he thought had nine months gets pushed to finish in six and then even faster due to market pressures. The situation seems hopeless, but then he begrudgingly asks for help from a "guru" (on an ultimatum from his boss).  In this case, though, the guru isn't positive that he can solve the immediate problem - though he does think he can help Steve in general.  The guru leaves Steve alone for long stretches with various things to ponder - come to think of it, this isn't too far from "Jonah" in The Goal.  One thing that was interesting about this guru is that he often didn't have the answer - not that he didn't want to say, it seemed he truly didn't know (and was willing to admit it!). 

The story develops, and Steve learns a lot.  The guru introduces some TOC and Lean concepts, and some of Steve's business partners introduce some new ways of thinking as well. He learns about the constraint and why it is important to identify it.  He learns that forecasts are always wrong and spending too much time refining them is often time wasted. He learns ideas about smaller and smaller batches to create speed.

In the end, the team pulls off amazing feats and pulls the company from the brink of irrelevance.  One of the biggest things they do is break a huge conflict that sat at the bottom of their reality: take actions for the short term or take actions for the long term.  Do it fast or do it right, and they couldn't see a way to do both.

While the story is about the struggles of the development team and the larger business, one of the biggest take-aways for me is the way Clarke describes the Evaporating Cloud (or Conflict Diagram), which is a classic of the Theory of Constraints thinking processes.  He also combined it with some thinking from Kelvyn Youngman that brings in the 4 views of change.  Clarke has this available on his website as well.

CloudClassically, the Evaporating Cloud is a diagram to help articulate the logic behind conflicts that occur.  One describes an overall goal (A) and two needs of the system (B and C).  Each of the needs generates and action (D and D').  The two actions are where the conflict resides.  One reads it: In order to meet the goal, we must meet needs B and C.  In order to satisfy B, we believe we must do D.  In order to satisfy C, we believe we must do D'.  And D and D' cannot exist at the same time.  Just as important, taking action D puts need C in danger, and doing D' puts B in danger.  We are in a conflict.  Often organizations will find themselves swinging between actions as one need or the other becomes predominant.  But both needs are important - but we compromise to get less that full amount of each need.  A central tenet behind TOC is that all conflicts (of this type) can be removed - "evaporated."  The key behind these diagrams is what connects the lines - the process of building the diagram helps to expose the assumptions underlying the "we believe".  Why must we do D?  or D'?  What makes them conflict?  As you (and the team) think through this - talking it out often helps - the reasoning behind why one action or the other comes into play.  Could there be different actions we could take that allow us to meet both needs?

Cloud rolling rocks version

Conflicts are sometimes articulated with statements like, "On the one hand ..., but on the other hand ...." What Clarke has done in the book (through the guru) is to take this kind of statement and make the conflict cloud more physical.  Turning the cloud, so that "A" is on the top, he draws a stick figure with D and D' in each hand.  B and C on the shoulders - representing the "weight" of each need.  And then the common goal is the head.  He even take the idea of actions jeopardizing the opposite need: poke yourself in the opposite shoulder with your index finger.  I really liked how this description of the conflict diagram has a physical feel to it - much more visceral than the dry cloud on a white board or a piece of paper.  

The other thing he brings to the cloud is from Kelvyn Youngman.  The cloud can be mapped to the four views of change: the benefits and hazards of a change, and the benefits and hazards of not changing.  (This is best illustrated in the entertaining video on "resistance to change".)  In Clarke's setup, below each hand you add the pro's and con's of the action.  Understanding these pro's and con's helps to articulate the needs.  And it helps to draw out the assumptions underneath the arrows in the conflict diagram.   This is all described much better in chapters 13 and 14 - go read it there.

In the story, Steve and the guru develop the conflict diagram for Steve's software project.  But then later on, there are a couple other conflicts that don't get their own diagram.  What Clarke does though is describe Steve weighing the conflict in his hands and wriggling his shoulders as he thinks through the needs. There was even the line, "My shoulders ached from the weights I carried with me that day."  This language, for me, makes the conflict feel much more visceral.  (I've heard that TOC for Education encourages children to draw the conflict on the playground and stand in the boxes to discuss interpersonal conflicts.)  

Another classic "problem" in software or any knowledge-work environment is Parkinson's Law: usually formulated as "the work expands to fill the time allotted."  Clarke took another direction with this one in the software development world, "The scope of the project always expands until it's too big to fit in the time available to deliver it."  When development happens in big batches, people throw more and more into the project until it bursts.  He gives some great examples of this as he discusses the problem with a colleague (in Chapter 11).  They also suggest the opposite: if you cut the scope to make the delivery date more reasonable, people might relax or slow down.  This is the Student Syndrome: I don't need to worry because I have plenty of time.  (Note: People aren't bad, this is a natural reaction to the environment we are in.  And the extent of either of these varies by person / company / group.)

One final item: I've known for a while that Clarke has a sense of humor.  It's in the writing - the little things like the coffee jokes or the expensive-looking pen that the guru carries.  Or the fact that the book website is Clarke Ching www.Rolls.Rocks.  And his humor shows up in the sub-titles of the book.  On the Amazon page for the book, the subtitle comes up as "How to Ship YOUR Software Projects On Time, Every Time." But on the cover of the paperback it says "The Agile Business Novel."  And the Kindle on Amazon, the cover says "The Agile Business Novel (which never mentions Agile)".  But then on my Kindle device, it says "Accelerate AGILE using Goldratt's TOC."  And in the book itself, the subtitle shows up as, "Read this when your AGILE implementation sucks."  

Here is a quote for the day:

A schedule defends from chaos and whim. It is a net for catching days. It is a scaffolding on which a worker can stand and labor with both hands at sections of time. - Annie Dillard in The Writing Life from 2009

Heard on a the Manager Tools podcast* recently

One-time events create change like dieting only on your birthday and expecting to lose weight.

I love this statement, whether it has to do with the performance review process, or just about anything else.  

When we think of a change, the outward sign is that behavior or some other measurable signal has changed.  Attending a training course - or dieting for one day - will not create a lasting change.  The event must be followed by a regular course of action, coaching, check-ins, ... whatever is appropriate for the type of change desired.

* I am fairly certain I heard it on Manager Tools.  The quote appears in a section of a book that discusses performance reviews.  And this suggests that I probably heard this on the Manager Tools podcast on performance reviews from the beginning of the year. 

Picture a steaming coffee cup. Better yet, grab one and have a read!

KJolt Memberships

Follow jackvinson on Twitter

View Jack Vinson's profile on LinkedIn