Tag Archives: management

John Kotter on organizational design

A review of John Kotter’s new book Accelerate: Building Strategic Agility for a Faster-Moving World in HBS Working Knowledge offers both a summary of the book’s key principles and an excerpt from the book itself. The concept builds on Kotter’s earlier work that focused on adding speed and agility to large businesses, and advocates for creating an organization that has “two operating systems” – one for everyday business and a smaller, agile system that “sits alongside to focus on the opportunities and demands of the future.”

Under a dual operating system, all processes and activities that involve what a company already knows how to do stay on the regular, hierarchical side of the company. High-stakes initiatives that involve change, speed, innovation or agility, go to the new agile network.

Reviewer Kim Girard continues, emphasizing that Kotter is not looking to abandon the traditional hierarchical model, but enhance it:

A dual operating system is a nod to what Kotter believes is some of the most interesting management thinking of the past few decades, from Michael Porter’s “wakeup call telling us that organizations need to pay attention to strategy much more explicitly and frequently,” to Clayton Christensen’s insights about how poorly companies handle the technological discontinuities inherent in a faster moving world. Kotter also credits recent work by Nobel Laureate Daniel Kahneman, who describes the brain as two coordinated systems, one more emotional, the other more rational.


In a typical organization—from the federal government to a pharmaceutical giant—a hierarchical operational structure meets daily demands through clear reporting relationships and responsibilities, Kotter writes. This structure minimizes risk, keeping people in boxes and silos, sorting work into departments, product divisions, and regions. Trouble is, managers in hierarchical organizations don’t promote or reward risk and innovation—they rely on routine, and turn to the same trusted people to run key initiatives.

Girard goes on to discuss Kotter’s 5 key principles for the dual operating systems, which ensure that the system works as envisioned (an “enhanced heirarcy” that focuses on leadership and innovation) and 8 accelerators that help managment tackle big opportunities for change. The accelerators are strikingly familiar, as many seem to have been adapted from Charles Duhigg’s The Power of Habit. Overall, an interesting approach to organizational design.



One of the people I’m coaching at work has been resisting delegation even though she feels overwhelmed. Her main concern is that delegation takes too much time, because most people don’t do the task right and she has to go back and re-do it anyway. We’ve talked through figuring out which tasks are best for delegation: tasks easily taught, tasks that will be repeated multiple times in the future (so investing time in initial training is worthwhile), tasks where imperfection can be tolerated, etc. This has worked well for relatively simple, rote tasks that need to be delegated, but is not enough guidance for larger projects.

In preparing for our next coaching session, I found an article from Bridgespan entitled Effective Delegation in Three Simple Steps. It describes delegation as “a balance between trusting others to get the work done and taking steps to ensure that those you’ve delegated to have the support needed to meet expectations.” 

I’ll be sharing the full article with her, but thought I would also summarize here. Step one is to hand over the responsibility and agree on expectations (cover what the project is, why the project is important and why you chose this person to handle it, who else is involved and should be included, where the person can get help and resources, when it needs to be done, and a little bit of how it should be done). Step two is “don’t delegate and disappear,” which seems simple. However, it can be difficult to strike the right balance between hovering over someone as they work and waiting too long to find out they’ve put too much time and energy into going in the wrong direction – the article has a good discussion of one example and how it was handled. Step three is “create learning opportunities” which reminds us to debrief on how the project went, even (especially) if it went well – often we learn from our mistakes, but forget to take the time to learn from our successes as well.

I also printed out a worksheet from The Management Center, linked in the article, that provides a framework to help think through assigning roles when delegating. This framework, called The MOCHA Model, articulates the roles of Manager, Owner, Consulted, Helper, and Approver. We just had a meeting last week where we found that a project had stalled because roles and responsibilites were not clear, so I think this will be really helpful as well.