Proactivity? Or Reactivity in Diguise

Being proactive is a sought after quality

WE ALL APPRECIATE THE SKILL to look into the future, evaluate potential impediments and then spring into action in an effort to resolve/mitigate the likelihood that they will occur. This is what we look for from our leaders.

This way of being is in stark contrast to reactive managers. No one likes working on a reactive team – it’s chaotic at the very best. I think of my time as a “sustaining” engineer, on a team that released monthly bug fix patches. There wasn’t much planning, just fixing the next batch of critical issues as quickly as possible. REACTING to the deficiencies of the product produced by the “Core” team.

Where we run into issues is when the lines between proactive and reactive blur.

Sanger calls this “the illusion of taking charge”. 

                   

What he means is false proactivity                     

As a child of “the Enemy is Out There” syndrome, (where external forces are identified as the cause of all organizational/departmental woe) the illusion of taking charge attempts to remedy the mal-effects ahead of time –> “proactively”. But care must be taken to consider whether these in-advance solutions are changing the company for the better (accelerating learning), or if they are merely REACTIVITY in disguise.

From the example that Sanger cites, I propose a cost benefit analysis as the determining factor. If the solution is proactive (ahead of the issue), then there is time to consider (a heads opposed to true reactivity in the heat of the moment). A back of the envelope CBA is sometimes enough to determine if the solution is beneficial to the organization.

Organizational Learning Disability - I am my position

Peter Senge describes the serious challenges that many organizations face when they learn poorly.

Unfortunately, because of the way we have been taught to think, these disabilities are very common. In his book, The Fifth Discipline, he reviews seven of these challenges that he defines as Organizational Learning Disabilities.

The term "learning" however, is defined differently. Rather than referring to the most common usage, Senge's meaning is more about how an organization achieves its potential - for itself and for its employees. Growing in a meaningful way, better able to face new market challenges, and avoiding the fate of many corporations -> an early extinction.

The first leaning disability 

addressed is named 

"I am my position"

The first leaning disability addressed is named "I am my position".

This is a fairly familiar syndrome and I'm sure that most of us have either said (or been in conversations with people that have said) "I'm a ". We identify with what we do. THIS is the most common symptom of this disability. However, it is not the only manifestation.

In "I am my position" there is also a hyper-focus on a person's individual role and responsibilities. With that singular vision, there is the concern that contributors fail to see how they connect with those around them. As an example of this, Sange gave the example of the Japanese v. US auto makers.

To summarize the example, Japanese engineers secured their engines with the same bolt in all three mountings. Contrasted that with US automakers, who assigned each of the 3 mounts to separate engineers - each responsible for one mounting bolt. Because the US engineers focused on THEIR mount only, and not thinking about how they connect with the other engineers, they each chose unique bolts. Because of that, assembly took longer and was more costly – had to keep multiple bolts in inventory.

Think about how this may be in-play in your organization. Do you produce monthly status reports? Do you have multiple deliveries of these reports in individual formats and decks? Are there multiple meetings? If so, your resources are spending time doing redundant work - just like the engineer with the engine bolt that should have conferred with his fellows. Management team should standardize on status reporting. AND in an agile environment, status report standardization is easy.

This is one of the organizational leaning disabilities that is addressed and remediated by Systems Thinking and the growth of the Learning Organization.

Times, they are a chang'in

One of the toughest things to deal with as an agent for change is how people deal with change.

As any type of manager, we constantly look for efficiencies.
Even leaving "process innovation" and its goal of 10x change out of the equation, there are significant gains to be had by implementing a continuous improvement program. Whatever system we are working with, near the top of our managerial todo list must be improvement. This means process efficiency.

Efficiency comes in many flavors and doing a deep-dive into current processes gives us the insights needed to streamline and make better. However, a mistake is to think that our changes (no matter how nobel) are going to be accepted. We have to understand what we are asking and plan strategically for the implementation.

There are two types of change: technical and adaptive.

Making technical change is about picking up efficiency by shifting process - an example would be moving from sticky notes on a white board to a computerized system like Jira. This requires a change in process and tools and will certainly add the benefit of visibility. It will also make backup and arching easier. It won't however force anyone to think differently.

Making adaptive change requires an underlying shift in what people believe. This may come is the form of relinquishing power over certain functions and changing scope on the way their team contributes to projects.

Lets consider a fictitious sales manager who is used to acting as de facto project manager.

In this capacity, project changes to support sales get weighted heavily.

This most likely will frustrate an efficient project delivery.

Changing project leadership from the sales manager to the project manager will force everyone on the tea to behave differently. We clearly see the benefits of this change with more timely deliveries, clear project scope, less stress on the teams, improved customer satisfaction. The sales manager (and maybe even the team) however may find it difficult to ADAPT.

As champions of change, we have been given a mandate for improvement that we are happy to accept. After all, inspiring program efficiency is a worthwhile task and a satisfying aspect of our career. However, strategic change is prudent. Take the time to demonstrate your value first. Plan your changes over time. Remember, the mandate and promise of senior management support today can go away tomorrow if too many feathers are ruffled in the process.

Good luck!

Emergent Design

Basically this post is to point to a fantastic article at ProjectManagement.com.

There are a lot of agile primers out there that explain the basics of running agile projects, but they lack implementation details that we as experienced software professionals are concerned with.
For instance, when I first started to learn about agile (after many years in waterfall), I wondered about up-front design.

"How can a scalable infrastructure be developed with a focused view of  deliverable slices of functionality?"

Dr. Rico has authored a detailed article that explains the ideas of Just Enough planning and Emergent Design. Interestingly enough, he recommended a book by Mike Cohn that I am currently rereading.

In summary, please read about these techniques and enjoy the references to further reading.

Dr. David Rico

 Read Dr. Rico's article HERE

Brainstorming as a Culture

Brainstorming That Works describes it the following way:

The expression brain storm and the word brainstorming was popularized in Applied Imagination by Alex Osborn. The word is a perfect description of the brain's process. Many synapses start firing and multiple associations stored in the brain get recalled. The point is to get so many thoughts coming up simultaneously and triggering so many other thoughts and ideas that your mind's alter ego that likes to think negative thoughts can't get a word in edge wise. 

The little boat is the problem statement :)

So what does brainstorming require? Well really, it is a very simple list.

1. As stated above, have a clear problem statement. What is the goal of this session? Don't be so focused that you limit the innovation, but still be clear.
2. Everybody participates. I'm highlighting that one because it is the one I feel is most important. I am dedicated to the Learning Organization and this is a big part of that. I don't think you'll get the best ideas if your STORM is limited to a room of architects. 
3. As Tom Kelley states in his book, set a goal for a one hour meeting. He found that 100 ideas in that time equals a good session.
4. Have fun. Consider this a benefit. You are creating a culture that will attract the best talent. Allow the comedic solutions, in fact, encourage them. 

As a Learning Organization we all strive to utilize all brain power to spark innovation. Brainstorming is a must-have in this culture. Not once-in-a-while, but constantly. 

The more it is used, the more influence it will have on your corporate culture.

You'll see creativity sparking here and there on a regular basis because the juices are flowing and everyone feels that it is not only allowed to contribute on this level, but expected.

Once word gets out, you'll enjoy knowing that you've just updated your company's reputation to "a cool place to work"

In summary, by implementing brainstorming into your planning or sprints, you'll generate more innovative ideas, foster a more collaborative environment, strengthen your learning organization, and build a better reputation that'll attract and retain the best talent. .
Oh yeah, and it is practically free  :)

ENJOY

The Lean Startup

The Lean Startup on Amazon

I've been re-reading Eric Ries' amazing book.
It is just as good the second time through - not a skim and jump around read, but good enough as a text to go cover to cover.

What you'll find here is the foundation for building a company. This book wasn't around when I was doing my MBA, and we were given "The New Business Roadtest". I'm sorry for that, because this book belongs in the required reading of any MBA, especially those that focus on entrepreneurship.

This book complements some of my other favorites, The Fifth Discipline and Davenport's Process Innovation.

For companies that strive to build a Learning Organization (and the best ones do), the Build-Measure-Learn feedback loop is integral to driving for success.

10X v 10%

The title looks like a horrible math problem.

However, in reality what it comes down to is "Innovation & Improvement: Not the Same Thing"

I've recently decided to go back to basics and re-read the best book on 'Process' ever. I refer to Davenport's HBS edition of Process Innovation. If you can read past the early 90's predictive voice in regards to IT, the rather immutable facts present themselves. Its best to start by just getting the terms defined.

There is a lot of confusion in the terms -to name a few:

• Process Redesign
• Process Improvement
• Continuous Improvement
• Process Innovation

Davenport makes a dramatic distinction between Process Innovation and Improvement.

Process Improvement sets it's goals at 5 to 10%

Process Innovation however has goals of 50 to 100%. That's a 10X change

So does that answer the question as to whether these terms are interchangeable?

Yes, there is a huge difference between them.

Does this mean that we should choose Process Innovation over Process Improvement?

No, they work together.

Buying a new car is a big change, but you need to have a maintenance plan or it'll break down.

Process Innovation effort makes large cultural changes across organizational areas (big risk - big reward). Process Improvement continuously updates the resulting processes to make them more efficient over time.

These two disciplines work together for the health of the business.

Process Innovation handing off to Process Improvement.