Posts From June, 2012

I Love This Book! The Culture Code

Build Your Project Team Culture

The Culture Code Reveals the Power of Safety

“When we talk about courage, we think it’s going against an enemy with a machine gun. The real courage is seeing the truth and speaking the truth to each other.”
         –Dave Cooper, Retired, Commander Master Chief, SEAL Team Six (From The Culture Code, by Daniel Coyle)

Why is it so hard to see the truth and speak the truth to each other? Why does that demand courage? And, can any team reach their potential without this ability?

Safety: The Foundation of High Performance

Daniel Coyle, in his new book, The Culture Code, offers three necessary cultural elements of what he calls “highly successful groups.” These elements are safety, vulnerability, and purpose. After reading the first few chapters, I became convinced that safety should be the primary focus for every leader, especially project leaders

I’ve always thought of safety at the office and in my work group as physical safety. Coyle refocused my attention to that of emotional safety. Frankly, I am surprised I haven’t seen it before. I’ve been reading and writing about project team performance for about twenty years. I’ve always known that trust is crucial to creativity and innovation, but Coyle’s angle brought a fresh light on the foundational role of safety. His theme is that for teams to reach their potential, each member must feel safe enough emotionally to be vulnerable. Vulnerability is critical to giving and receiving authentic feedback, which is the only way a group will improve its performance. Feedback within the group is directed toward serving the purpose. Purpose becomes the North Star. That logic is tough to dispute.

Project teams are temporary, formed to accomplish something unique. These teams solve problems and make decisions every day. Versatile’s high-performance team checklist lists nine characteristics that enable a team to survive the “give and take” of creativity and problem solving while maintaining trust and keeping relationships intact. But I have to admit that emotional safety has always been assumed, rather than explicitly called out.

Coyle’s logic, that safety precedes trust and trust precedes authentic feedback and team learning, lays bare the importance of establishing emotional safety within our teams. The quote at the beginning of this article comes from a key story in the SEAL Team Commander’s evolution as a leader. In Cooper’s early career he advised a superior that a particular course of action was dangerous and should be avoided. That superior ignored his  advice and the result was exactly what Cooper had feared. Cooper took away from that experience a desire to be the kind of leader that invited opposing points of view and encouraged criticism from every member of his team.

The Primary Focus of Every Project Leader

Do you want your team to “see the truth and speak the truth to each other”? What could be more important? From creation of a business case and charter, through risk identification, scheduling, and daily problem-solving, your team is making decisions and working through conflicts.  Every day of every project is affected by team culture. Pick up Daniel Coyle’s Culture Code. He illustrates his theme with stories from a wide range of teams and follows up with specific actions for the reader. I predict his lessons will stick with you and reignite your focus on team culture.

Six Project Myths That Won't Go Away

You just can’t shake some myths.

  • Don’t swim for an hour after eating or you’ll get cramps and drown. (What kind of cramps make you drown?)
  • Santa Claus only brings toys to good boys and girls. (If this were true there would have been a noticeable difference under the tree penalizing my brother.)

It seems no amount of objective explanation can put these to rest for good. 

Projects have their own myths and no matter how many times we fight them, they live to haunt us another day.  We’re getting some help this month from the Harvard Business Review.  Co-authors Stefan Thomke, from Harvard’s B-school, and Donald Reinertsen, call out six myths in the context of new product development.  As they point out, these myths persist because managers bring an operations perspective to the project environment.

Here’s a quick recap of their six myths.  How many do you recognize?

One. High utilization of resources will improve performance.  This myth seduces with its simplicity.  Keep people busy by launching a lot of projects. With your people “fully utilized” you have your product development operation humming at maximum capacity.  The reality: people spend a lot of energy switching between projects.  Ten projects are started but progress on any one of them is hurky-jerky. It’s a traffic jam and the leaders have failed in their responsibility to prioritize and focus their resources. (A previous post provides the formula for battling this myth.)

Two. Processing work in large batches improves the economics of the process.  This is the classic “waterfall failure.”  A completely linear development lifecycle has phases that resemble this flow: Requirements, Design, Construct, Test, Release.  The ‘large batch size’ problem is that if you are building a complex product and wait until the end to test it, you may find so many failures that you literally cannot fix them all.  The solution is the Lean/Agile approach of iterative development: finding components that can be designed, constructed, tested, and released to production.  Sure, some products lend themselves better than others for applying this concept, but any product can benefit. (A non-software example is used to explain this concept in a previous post.)

Three. Our development plan is great; we just need to stick to it.  Again, the authors pinpoint the source of the myth as an operations mindset: “Such thinking is fine for highly repetitive activities in established manufacturing processes. But it can lead to poor results in product innovation, where new insights are generated daily and conditions are constantly changing.”  Put another way, “No battle plan survives first contact with the enemy.”* That doesn’t argue against planning, it argues in favor of planning to discover.

Four. The sooner the project is started, the sooner it will be finished.  This is a re-hash of myth #1 but with a different motivation.  This myth stems from the belief that initiating a project creates forward progress that, no matter how small, can be built on later.  The result is the same as trying to “keep everyone busy” (myth one). It ignores the reality that developing a new product demands some creativity, focus, and momentum.

Five. The more features we put into a product, the more customers will like it.  This is like the Santa Claus myth – how can anybody really believe it?  Yet it endures.  In fact, this is a recipe for over-budget junk. The article’s authors summarize the dilemma with a timeless truth: “Articulating the problem that developers will try to solve is the most underrated part of the innovation process.”

Six. We will be more successful if we get it right the first time. The mistake is believing that in a product development process it can be done right the first time. Rather, “Teams that followed an iterative approach and conducted early and frequent tests made more errors along the way. But because they used low-cost prototyping technologies, they outperformed teams that tried to get their designs right the first time.”  If we are going to be developing something new, shouldn’t we expect to make mistakes and plan to discover along the way?  Designing an effective iterative development cycle is no small feat, but it is the right place to focus.

I recommend this article.  It’s like the summer movie blockbuster, The Avengers: The plot is familiar, but the story is fresh and feel-good. 

And you’ll leave re-energized to keep fighting these myths.

*Prussian Field Marshall Helmuth von Moltke