Culture Eats Methodology as an Appetizer

October 3, 2016 — Posted by Marc Danziger

Peter Drucker apparently never actually said "Culture Eats Strategy for Breakfast." But it doesn't matter, because it's just flat true. (For the record, it appears to have been Mark Fields of FoMoCo in 2006 although the origin remains clouded.)

I want to extend it by suggesting that culture eats methodology too.

Any effort to put a methodology in place that doesn't take into account culture is a fool's errand. How many failed efforts at instituting Agile - or any methodology - can you think of? (Hint - many.) What drove the failure? Most often, the rejection of the change by the dominant culture of the organization.

People pay attention to the culture of an organization before trying to change it way too seldom. We seem to act as though culture doesn't exist until it starts to push back.

Additionally, we - as methodologists - need to acknowledge that an organization with a strong enough culture might not need methodology.

I know, I know, heresy.

But let's be honest. Many of us have been able to be a part of extraordinarily high-performing teams that operated without a formal methodology - much like great jazz combos manage to make beautiful and complex music without scores.

Go back and reread Coplien's seminal paper on Borland Quattro Pro. In 1994 - just as the ideas for Agile were germinating - a team simply did it. The paper calls out several factors - trust; flat organization; high levels of peer-to-peer communication; close alignment of product vision because the business owner participated closely. All things we try and drive toward in implementing an Agile methodology - and all things they had without it.

So, before there were strong team methodologies and without them, lightning was captured in bottles and we had ridiculously high performing teams. I've been part of more than one. I'll bet a lot of people reading this have, too.

But we're not all Miles Davis. In fact a vanishingly small number are. And I'll note that it was the Miles Davis Quintet - not the Miles Davis Quinquagintatet (that's Latin for 'fifty').

But it is a fatal mistake to think that we can replace culture by simply implementing a methodology. Culture can, if it chooses, reject methodology. We've all lived it.

The way I look at it is that methodology is a scaffold on which to grow a new culture. Methodology should support the growth (or regrowth) of the kinds of culture we want and need.

What might the characteristics of that kind of culture be?

It's a subject for many late nights and lots of brown liquor, but Google has - unsurprisingly - gathered the data and made the call.

In 2014/15 they ran 'Project Aristotle' and ran the data on high- and less high-performing teams at Google. Their hypothesis was that 'impact of work' mattered the most - that when a team believed in the work being done's impact, they'd invest more heavily in doing it.

Wrong.

Number One, with a bullet (metaphorically - think Billboard, not 'Kill Bill') was 'psychological safety' - trust.

"Psychological safety was far and away the most important of the five dynamics we found -- it’s the underpinning of the other four. How could that be? Taking a risk around your team members seems simple. But remember the last time you were working on a project. Did you feel like you could ask what the goal was without the risk of sounding like you’re the only one out of the loop? Or did you opt for continuing without clarifying anything, in order to avoid being perceived as someone who is unaware?"

It goes far beyond this. Honesty is a byproduct of trust, and honesty is the key to success. 'Deep Survival: Who Lives, Who Dies, and Why' as a great book about people in extreme situations, some of whom survived - and some of whom didn't. The author, Laurence Gonzalez, is fascinated by the question "What's the difference between survivors and the victims of tragedy - other than luck."

Here's what he says.

"The world we imagine seems as real as the ones we’ve experienced. We suffuse the model with the emotional values of past realities. And in the thrall of that vision (call it “the plan,” writ large), we go forth and take action. If things don’t go according to the plan, revising such a robust model may be difficult. In an environment that has high objective hazards, the longer it takes to dislodge the imagined world in favor of the real one, the greater the risk. In nature, adaptation is important; the plan is not. It’s a Zen thing. We must plan. But we must be able to let go of the plan, too."

or, more pithily:

"To deal with reality you must first recognize it as such."

I can't think of a better goal for an organization, or a better test if you're unsure of how healthy your organization's culture might be.

Do your people trust each other enough to recognize reality?

And if Agility is your goal (as we think it should be) this question is a great place to start.

 

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Marc Danziger

Marc Danziger is a proven leader and team-builder, technology visionary and problem solver. He has successfully led programs & developed products in a wide range of technologies for clients ranging from new startups to Fortune 100 companies. His core experience is in three areas:

  • Envisioning new products or systems;
  • Delivering technology, often by turning around troubled projects;
  • Improving organizations by designing and implementing improved processes.



        

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban