The podcast by project managers for project managers. Hear about the three attributes of restraint: speed, thrift, and simplicity – and how these traits can add to project innovation. Dan Ward describes using a restrained approach of short schedules, tight budgets, small teams, and deep commitments to simplicity to deliver best-in-class technology that is operationally relevant. He highlights how unnecessary complexity adds complications which can reduce innovation.

Table of Contents

01:40 … Dan’s Book LIFT
02:46 … High-Speed, Low Cost Programs in the U.S. Air Force
04:28 … MITRE Innovation Toolkit
06:12 … When it’s Not All About The Bass
08:25 … Project Success on a Shoestring Budget
13:33 … Speed, Thrift, and Simplicity
16:03 … Unnecessary Complexity Reduces Innovation
22:00 … Innovation Requires Diversity
25:06 … Stay on Track with Innovation
28:03 … Status Reporting
32:19 … Eating the Failure Cake
36:09 … Get in Touch with Dan
37:09 … Closing

Dan Ward: …it turns out we get better results, more innovative results, more impactful results, when we move in the direction of speed, thrift, and simplicity, rather than moving in the direction of spending more time, more money, making things more complicated. 

WENDY GROUNDS:  Welcome to Manage This, the podcast by project managers for project managers.  My name is Wendy Grounds, and with me in the studio is Bill Yates.  And we’re so glad you joined us today.

We have a special guest.  His name is Dan Ward.  And he’s an innovation catalyst at the MITRE Corporation.  Dan previously served for more than 20 years as an acquisition officer in the U.S. Air Force, where he specialized in leading high-speed, low-cost technology development programs.  Dan retired at the rank of Lieutenant Colonel.  While he was on active duty he helped establish the Air Force Research Laboratory’s rapid innovation process.

BILL YATES:  Dan Ward is also the author of three books.  We’ll talk about “LIFT” specifically in the podcast that he released in 2019; “The Simplicity Cycle,” 2015; and “F.I.R.E.” in 2014.

WENDY GROUNDS:  In our conversation with Dan we have a particular theme of innovation and managing complexity.

BILL YATES:  Yeah.  So Dan has researched, of course his career was dedicated to this as well, and he’s written books on this idea of innovation and applying innovation to various environments.  Certainly for project managers we can look at this, and we’re going to share some advice and learn some lessons from this man as we talk about innovation and how to apply it to our projects.

WENDY GROUNDS:  Hi, Dan.  Welcome to Manage This.

DAN WARD:  Wendy, thanks so much for having me.  I’m looking forward to this chat.

Dan’s Book LIFT

WENDY GROUNDS:  Yeah, no, we are happy to have you.  And first thing we want to talk to you about is your books.  You’ve written a few books.  And your latest one is called “LIFT.”  Can you tell us a little bit about that?

DAN WARD:  Yeah, absolutely.  So “LIFT” was such a fun book to write.  And it takes a close look at what I think is a really interesting part of history, the late 1800s, and then specifically the people who were trying to build airplanes in the decades immediately prior to the Wrights.  So all of these people failed.  None of their airplanes actually flew.  That wasn’t until 1903 when the Wrights had their first successful airplane.

But these experiences, these experiments, and the way they handled their failures have a lot of really interesting applications for challenges people are working on today.  So in terms of like solving hard problems, managing intellectual property, collaboration, diversity, equity, and inclusion.  You know, we think we invented that.  No.  They were dealing with those types of issues in the late 1800s.  So really, anyone who’s trying to solve an unsolved problem or just even just a really hard problem, we can learn a lot from these aviation pioneers in the late 1800s.  And it was so much fun to tell their stories.

High-Speed, Low Cost Programs in the U.S. Air Force

BILL YATES:  Our understanding is you had a long career with the U.S. Air Force.  And through that there are a lot of lessons learned.  So we’d like for you to talk to us about some of your experience in the U.S. Air Force and leading high-speed, low-cost technology development programs.

DAN WARD:  Yeah, absolutely.  So I spent about 20 years in uniform as an active duty officer, an engineer, and a program manager.  And, you know, pretty early on I noticed an interesting pattern, that most of my frustrations and failures were when I was part of a cast of thousands, and we were spending decades and billions to develop some new shiny piece of wonder tech.  And then all my biggest successes and my proudest moments in my career were when I had a small team and a tight budget and a short schedule. 

So I kind of leaned into that.  I studied it.  I experimented with my own career.  And I wrote some books then about how to use this restrained approach of small schedules, tight budgets, small teams, deep commitments to simplicity; how we use this to help us deliver best-in-class, first-in-class technology that really is operationally relevant.

So, for example, the last program I led while I was in uniform was actually the smallest program in my department.  We had the smallest team, the smallest budget.  The team was actually already shrinking before I took over.  The budget had already been cut.  And when they asked if I’d like to lead that team I was like, oh, heck, yeah.  This is a great chance to put my money where my mouth is.  And at the end of the day we delivered ahead of schedule.  Our first test flight – it was an airborne radar system.  We did our first test flight a month ahead of schedule.  We collected twice as much data as originally planned or promised.  And we came in $7 million under budget.  It was a great program to kind of cap off my time in uniform.

MITRE Innovation Toolkit

WENDY GROUNDS:  Dan, we want to move on to what you’ve done next.  You’re currently working for the MITRE Corporation.  Can you explain to us what your role is there, and also something called the MITRE Innovation Toolkit that you’ve been part of.

DAN WARD:  So MITRE is a really cool place to work.  I love it here.  We are a not-for-profit company, and we are chartered to work in the public interest.  So we bring deep technical expertise to some of the government’s biggest problems and challenges, and that’s on everything from public health, things like the equitable distribution of vaccines, to cybersecurity, to improving the user experience for the IRS.  So my unofficial job title is innovation catalyst.  And I think my formal job title is system engineer of some kind.  There’s a bunch of other words in there.  But innovation catalyst is what I put on my business card.

So I’m part of this team at MITRE called the Innovation Toolkit team.  And our mission on this team is pretty simple.  It’s to help people understand what innovation is and then how to do it.  So we’ve developed a set of tools.  We help people figure out which tool to use.  We’ve got about two dozen on our website.  And then when to use the tool, and why to use the tool.  We help them go through the process of applying these tools to their projects, their programs, their departments, their processes, their technology.

And one cool thing about being a not-for-profit working in the public interest, our tools are all free to use.  So anybody can go to itk.mitre.org.  MITRE is spelled M-I-T-R-E, and ITK stands for Innovation Toolkit.  So that’s itk.mitre.org.  And you can download the full set, you know, all 26 of them.  There’s 26 tools there.  And for each one there’s a description of what is it, when would you use it, why would you use it, how would you use it, and then templates and downloads and enablers to help you put that into practice.

When it’s Not All About The Bass

BILL YATES:  That’s fantastic.  We’ve had some really interesting conversations on past podcasts about innovation.  I think about our conversation with John Carter.  John and Dr. Bose, they have the patent on the first noise-cancelling headphones.  And I remember, what was so fascinating was John described to us, he said, we started out on this project thinking that the bass was going to be the key.  We thought if we could make headphones that have really rich bass, that’d be the best, you know, the customers would love it.  But then some of the early feedback they received it was not about the bass.

WENDY GROUNDS:  See what you did there.

BILL YATES:  Yeah, yeah.  Stepped into that nicely; right?  It was not about the bass.  It was about the noise cancelling, a feature that they had included that to amplify the bass, and not realizing that was going to be one of the keys.  So this idea of innovation is so interesting.

DAN WARD:  So that reminds me of something actually from the book “LIFT.”  A German engineer named Otto Lilienthal, he was literally an engineer, like he developed engines.  And the engines that he had designed were lighter weight and more powerful than anything else on the market, so much so that he retired at like 40.  He retired fairly young and just dedicated the rest of his life to building airplanes.  Now, we would think that to build a successful airplane you need a lightweight powerful engine.  Oh my gosh, that’s his expertise.  What he discovered pretty quickly, though, is that it’s not about the bass.

But it turns out that the engine wasn’t the next problem to be solved.  He spent most of his time building gliders, flying structures that do not have engines, because what he realized in just an amazing moment of humility, of just professional humility, was that, hey, he has good engines, but the engines aren’t the next part of the problem to be solved.  Until you manage stability, until you have control over the aircraft, your engine is irrelevant.  It doesn’t matter how strong it is, how powerful it is, how lightweight it is.  If you can’t control your pitch and your yaw and your angles and all that, the engine doesn’t matter.

And he was able to make that leap.  He was able to make that shift and to go from being best in the world at building powerful engines that are lightweight and said, all right, we’re going to set those aside for now.  We’re going to focus on stability with our gliders, lower, slower, and make tremendous progress. 

Project Success on a Shoestring Budget

BILL YATES:  This is so interesting.  And I know, you know, you mentioned the Wright Brothers, how these two guys just put together their pennies and with duct tape and shoestring they started building this thing and testing it and improvising on it and changing it.  This is so relevant in today’s economy.  Sometimes project managers have to lead a project, and they have a shoestring budget.  They have a tight schedule.  So what’s the secret to successful innovation or project delivery on those frugal projects versus a project that has all kinds of time, money, or maybe complexity involved in it?

DAN WARD:  So one of the main messages in my first book, “F.I.R.E.,” is that constraints foster creativity.  So instead of trying to solve our problems by adding time and money and complexity, lean into the constraints and apply intellectual capital instead of financial capital.  I think Winston Churchill famously said at some point in World War II, “Gentlemen, we’ve run out of money.  Now we must think.”  And I think there’s such wisdom in that perspective.

And going back to the Wrights, for example, I do tend to refer to them as “the Wrights,” rather than “the Wright brothers,” because their sister Katharine was a full participant in their work.  Wilbur even said, “If history remembers us related to aviation, it must remember our sister.”  So of course history promptly forgot their sister and calls them “the Wright brothers.”  I call them “the Wrights” or “the Wright siblings.”  But they spent about a thousand dollars on their experiments and their initial designs and building that airplane that successfully flew.

And you can compare that with a guy named Samuel Langley, who was a contemporary and a competitor to the Wrights.  Samuel Langley spent $73,000, so 73 times more than what the Wrights spent.  He had teams of people with Ph.D.s.  He had government contracts.  And his designs had an annoying tendency to just go, you know, nose down into the Potomac.  All that money, all the Ph.D.s, all the formality of it did not actually help him deliver a good solution.  Now, that doesn’t mean we’re against education, you know, I have several degrees myself.  There’s nothing wrong with having some money.  There is an amount of money that’s too little.  But there’s also an amount of money that’s too much.  And I think in technology circles we tend to err on the direction of spending too much money rather than too little.

So I can give you one quick example from my first book, talking about the U.S. Navy’s Virginia Class Submarine program.  I love the Virginia Class Submarine.  It is just a terrific example of this thrifty, restrained approach to innovation and problem solving on something as large and complex as a nuclear-powered sub.  So after the submarine was fielded, and incidentally the Virginia sub cost less than half of what its predecessor cost, the Sea Wolf sub.  So after it was fielded and we’d been operating it for a while, the Navy asked the question, hey, what’s the worst thing about this sub?  What improvements could we make?  And the crew said, hey, look, the periscope controller is heavy, it’s clunky, it’s hard to use.

And someone – man, I would love to shake this person’s hand – someone suggested they replace the periscope controller with an Xbox controller, since everyone already knows how to use an Xbox control.  They cost $30.  The previous periscope controller cost $39,000.  An Xbox controller costs 30 bucks.  And you can get a spare at any port in the world.  So they tried it out.  It worked great.  And that’s what they went with. 

And the nice thing about that experiment is they were able to say, hey, take one of these subs.  Let’s remove the current clunky controller, put in the Xbox controller.  If it didn’t work, all right, fine, put the old one back.  If it does work, though, now we’re going from a $39,000 piece of equipment to a $30 piece of equipment that actually works better and solves the hard problem.  That’s the type of resource-constrained innovative thinking that I adore and write about extensively.

BILL YATES:  Yeah.  I love that story.  And just think of all the young listeners who are now inspired to maybe serve in the military just because of that.

DAN WARD:  Hey, if you can play the Xbox, you can operate one of these sub stations.

BILL YATES:  Right, right, right.  I could drive that nuclear sub.  It’s not a problem at all; you know?  I need to give you credit, too, so I’m going to have to give credit in the future.  We have a slide that we use in one of our main courses, our instructor-led classes.  And the title of that slide is “Constraints foster creativity.”  I need to put in there, okay, give credit to Dan Ward in “F.I.R.E.”

But it is, it’s such a great concept.  Those constraints can be – sometimes they’re part of the iron triangle.  Sometimes it is scope, sometimes it is schedule, sometimes it is budget.  But there are all kinds of constraints; right?  Sometimes it could be a compliance issue.  It could be something that the government has mandated.  Or it could be an internal compliance issue that our company has mandated.  You know, we’d like to use this software.  We’d like to use this VPN solution.  But we can’t because of this constraint.

There are so many times as project managers we have to be shocked out of our paths that we’re used to taking and our method for doing something and think, okay, time out.  Let’s all step back and take a fresh look at this because there is a constraint.  We need to get around this.  Just taking the constraints which we normally see as a negative and saying, no, no, no, there’s good in this.  We’re going to be better.  We’re going to be smarter.  And we’re going to be faster.  And we’ll have an improved product line into the future because of this constraint that we’re going to have to solve today.  I like that challenge.

Speed, Thrift, and Simplicity

There’s one thing that you mentioned, Dan.  I think it’s really a theme throughout your book.  And it’s the three attributes of restraint:  speed, thrift, and simplicity.  Can you tease that out some for us?

DAN WARD:  Yeah, absolutely.  So when I talk about constraints, I had to be specific about it.  What types of constraints are we really talking about?  And these are typically constraints on our time, so having a tight schedule, a near-term delivery date.  Constraints on our money, having a tight budget, constraints on team size, you know, some companies will talk about like the two pizza rule:  No team should be bigger than what you can feed with two pizzas.  And then constraints on our complexity, so not allowing complexity to expand unnecessarily.

But when we talk about complexity, that’s in our technology, as well as the complexity of our processes, our documentation, our PowerPoint slides.  And it turns out we get better results, more innovative results, more impactful results, when we move in the direction of speed, thrift, and simplicity, rather than moving in the direction of spending more time, more money, making things more complicated. 

And there are some bad heuristics out there.  There are some unreliable rules of thumb that we should just stop using, things like, oh, take your time and do it right.  You know, take your time and do it right means let’s go slow.  There’s something to be said for not being hasty.  And so when I talk about going fast, I like to distinguish being fast and being hasty.  Hasty is cutting corners that shouldn’t be cut.  Hasty is running around corners with your eyes shut and running with scissors, like I’m not about that.  But there is a fastest and shortest possible path between Point A and Point B.

Similarly, you know, you get what you pay for.  You get what you pay for.  Hey, we want a lot.  We’d better pay a lot.  So the more we pay them, the better it’ll be.  And we think there’s this direct correlation between the cost of the budget and the quality of the output.  And the data just don’t support that perspective.  So my heuristics are things like faster, better, cheaper, pick all three.  You might have heard faster, better, cheaper, pick two.  That’s another unreliable heuristic.  I think we should stop saying that because it turns out the data don’t support this as a rule.  This iron triangle is not really iron.

And when you look at what NASA did in the ‘90s with their faster, better, cheaper initiative, the thing that they discovered experimentally, like in the real world, was that it is possible to simultaneously improve the cost, the schedule, and the performance of an advanced scientific technical piece of equipment, and that you don’t have to sacrifice one of those legs of the iron triangle.  So Howard McCurdy wrote a terrific book called “Faster, Better, Cheaper” that lays out the details of all of that.  Highly recommend folks check that out.  Or my four-page article that sort of summarizes, if you don’t read his whole book.

Unnecessary Complexity Reduces Innovation

WENDY GROUNDS:  Dan, can you talk a little bit about unnecessary complexity and just how that adds complications, and how it can actually reduce innovation on a project.

DAN WARD:  Yeah, I love this question.  And, you know, if my first book was about speed, thrift, and simplicity, of those three things I felt like simplicity was the topic that needed a deep dive.  So that was actually the theme of my second book titled “The Simplicity Cycle,” which is all about how to make good decisions about complexity, and how to make good decisions under conditions of complexity as the world is such a complicated place.  Although I do advocate for simplicity, I also recognize there are times when making things more complicated makes them better.

And so the subtitle for “The Simplicity Cycle” is “A Field Guide to Making Things Better Without Making Them Worse.”  And again, it’s trying to give us a nuanced understanding of the relationship between complexity and goodness, of value.  And, you know, how do we go about making things better?  Our systems, our requirements, our processes, our PowerPoint slides.  Did I mention PowerPoint slides before?  Yeah, that’s big, a big topic that I love talking and writing about.  You know, the best ideas in the world are worthless – I use that word very deliberately – the best ideas in the world are worthless if we can’t express them clearly.  And so often the PowerPoint slides that we make for our corporate communications just don’t express the idea clearly.

You know, we treat complexity as a sign of sophistication, another one of those unreliable heuristics.  If we equate complexity with sophistication, this is the most complicated thing we’ve ever built, I must be really clever, you know, actually there’s some elegance to simplicity that correlates with value much better.  So how do we do this?  One of the key practices in this area is what I call “rapid iterative collaborative experimentation,” so the acronym is RICE – Rapid Iterative Collaborative Experimentation.  And so what we want to do is quickly implement a series of fast simple experiments that each builds on the ones that came before.  And we want to do this with the people who are affected by it.  That C in RICE is so important, the collaborative aspect of it.  So the users as well as the coders, really anybody who has an interest in the outcome.

So when we talk about simple experiments, any individual experiment should be simple, should be focused.  You know, we’re modifying one thing at a time.  But it’s the iterative nature of our experiments that, you know, we’re building on a whole series of these experiments.  Each one is fast, simple, and focused.  But the whole set, the whole campaign of experiments helps us get to reliable data about how the world works and what works in the world.  So that’s my latest acronym, RICE.  I’ve been just testing that one out to make the narrative work out right.

BILL YATES:  Yeah, yeah.  This is great, though.  And I love prototyping.  You know, it’s something we talk about from time to time.  But prototyping is such a key component with that:  Rapid, Iterative, Collaborative, Experimentative.  It reminds me, too, there was a mantra that came out as we talked with Dave Gibson about the MRAP program, the Mine Resistant Ambush Protected vehicles.  Throughout that program, they had this mantra of build a little, test a little, learn a lot.  It was all about we have to get something in theater as quickly as possible, get a solution to save lives in order to replace those Hummers with these better vehicles that can endure the IEDs with better success.  So the rush to get things to theater that would work meant that they took a different approach than your typical defense contract; right?

I think the example is like the Jeep used in World War II that was this massive program to choose the right Jeep and make that investment, versus MRAP, which had to get to the field as quickly as possible.  To that end, they were blowing things up; right?  They would build something.  They’d blow it up with the test dummies inside and quickly get important data they could put their hands on and then see, okay, how is this going to work in the field with real people?

DAN WARD:  Yeah, I was fascinated to watch the MRAP program unfold because it helped validate a hypothesis that I had.  And the hypothesis was that the long timelines, the huge budgets, and the high levels of complexity that are often associated with military technology or space technology or any kind of advanced technology, the hypothesis was that these long timelines, big budgets, and high levels of complexity were not inevitable attributes of advanced new technologies.  So what we saw with the MRAP was they said we must go fast.  And you know what?  They did.  So when we value speed, when we say speed is a desirable attribute, a positive element of this thing, that we can deliver stuff very fast.

But back to that idea of you get what you reward, you get what you value, our values drive our decisions, and this idea that we can value speed and still get good results.  We’re not sacrificing quality in the name of speed.  Or as somebody put it, the price of speed is quality for that heuristic turnaround.  And it’s just – it doesn’t hold up.  Like the data don’t support that assertion.  And so the MRAP was a good example of that.

Now, one thing that I think is interesting with the MRAP is they basically said we need you to go really fast.  Spend as much money as you need to.  Right?  We went really fast, and we spent a bunch of money.  I wonder what would have happened if they had said we need you to go fast and constrain your costs.  I would expect, based on experiences where we’ve done that, that we could have gone fast and, you know, not spent quite so much money.  And we could have incorporated more modular approaches, you know, focus on integration of the system with the larger supply chain and the rest of the larger environment, the technical environment that it needs to operate in.

So again, I think the MRAP is a great success story.  It helped validate that hypothesis that we can go fast when we want to.  And I think we can also go inexpensive when we want to.  We can go simple when we want to, when we choose to.  And we often don’t choose to because we have these heuristics that say take your time and do it right, or you get what you pay for, or complexity is a sign of sophistication.  So a lot of my work is sharing some of these stories and proposing a different set of heuristics, different rules of thumb to guide our decisions.

Innovation Requires Diversity

 BILL YATES:  This is just a side path that I want to take with you.  I appreciate the thought that you have on diversity, that bring people onto your teams that come from all different backgrounds.  Because that brings a different solution set and a different set of eyes to these problems.  One of the things that I love is seeing this theme where one industry learns something from another.  I think of the old commercials that had somebody with a jar of peanut butter and somebody walking along with a chocolate bar, and an accident happens, and then we have the birth of the Reese’s peanut butter cup, which I’m still so happy for that.

DAN WARD:  Right.

BILL YATES:  Yeah.  Speak a bit about the diversity.  How do we build teams that are able to kind of step back and see that big picture and not have blinders on?

DAN WARD:  When we go deep on Topic A, just like study as much as you can about Topic A, inevitably, without exception in my experience, you discover Topic A is related to Topic B.  So I dove really deep.  I went way down the rabbit hole on aviation in the late 1800s.  I learned so much about all the people who were doing these designs and doing these crazy experiments and building all these just bananas flying machines, and none of them worked.  And the more I learned about this particular domain, the more I saw parallels and comparisons and relations with other domains, with software, with the work that I do, you know, today in the early 2020s.

And so as a general rule, a general practice I find, go really deep on subject matter A, and you will inevitably discover parallels and connections with subject matter B, some other topic.  Which sets it up nicely for the topic of diversity.  You know, one of the big themes in really all my work is that innovation is a team sport, and that innovation requires diversity.  I just want to say that again.  Innovation requires diversity.  And there’s a ton of really compelling research showing that homogenous teams are less effective at solving hard problems than diverse teams are; and that the more dimensions of diversity, the more true diversity we bring to the team, the better.

So it’s not about tokens or about being satisfied with a bare minimum level of diversity.  Oh, phew, we checked that box, you know, we don’t need to worry about diversity anymore.  No, no, no.  It’s about actively, enthusiastically, deliberately doing the work to increase the diversity of our teams.  And that’s in terms of background and perspectives as well as gender, ethnicity, orientation, degrees of ability.  When you have teammates who don’t look like you, they don’t just bring different ideas.  They stimulate different ideas.

Put me in a team full of white able-bodied American men, and I will be less creative than if I’m in a more diverse atmosphere with people who don’t look like me.  So it’s not just that different people bring different perspectives.  Different people help me come up with different perspectives.  You know, I just – I keep going back to the data.  I’m an engineer by training.  I aim to be data-driven in my decision-making and in my designs and in my work.  And the data continue to be so compelling, so unequivocal that diverse teams are better at solving hard problems.  And so if I want to solve hard problems, I cannot allow myself to be in a bubble of people who look just like me.

Stay on Track with Innovation

WENDY GROUNDS:  Dan, first I want you to give us your definition of innovation.  And then if you could tell us if a project team is doing something that’s not been done before, they’re going to have lots of new challenges.  There are going to be unexpected challenges they’re going to have to face.  How can innovative project managers and project teams stay on track when they’re starting some new innovation?

DAN WARD:  Ah.  So really I love that question.  You know, I think one of the best things a leader or a manager can do is to build a shared understanding across their team of what innovation actually is and why we’re doing it.  So the definition we like to use for innovation on the MITRE Innovation Toolkit team, we define it as “novelty with impact.”  Novelty with impact.  I like that definition because it’s just three words, and so I can remember it.  I also like it because it’s broad enough to be applicable in a pretty wide range of situations.  So “novelty” could refer to new technologies or new processes or new formats for our PowerPoint slides.  Anything that’s new fits under that umbrella of “novelty.”

And then the “impact” refers to saving time, saving money, saving lives, you know, it might apply to maintainability, sustainability, all the “-ilities.”  Whatever the measures of merit are for any individual project, that’s under that definition of “impact.”  A slightly longer version of this definition, we talked about it as “something different that makes a difference.”  So the best thing about this definition, though, “novelty with impact” or “something different that makes a difference,” is it puts two really important questions on the table.  What novelty are you trying to introduce, and what impact are you trying to have?

What difference are you trying to make, and what’s different about what you’re doing?  So if as a team together, if we can have a shared understanding of what’s different about what we’re doing, and what difference are we trying to make, what novelty are we trying to introduce, and what impact are we trying to have, now we can really communicate clearly, build a shared understanding of what we’re doing and why we’re here.

So it might be this is a new technology that saves lives.  This is a new process that saves a bunch of time.  This is a new X that does Y.  And that helps us avoid kind of that, you know, innovation theater, or like innovation for innovation’s sake, because really when we talk about innovation for innovation’s sake, it’s what’s really happening there is that’s just novelty without impact.  And innovation without impact is just novelty, and we like novelty.  Novelty is fun.  But novelty alone isn’t innovation.  It needs to solve a problem, provide some value, make a difference, make things better.

And so two words we use a lot on Team Toolkit are “clarity” and “consensus,” establishing understanding and getting buy-in.  And so to your question of what would a project manager or project leader do to help their team stay on track I would say help build clarity and consensus.  Build a shared understanding and a shared commitment to what’s novel about what we’re doing and what impact are we trying to have.

Status Reporting

BILL YATES:  I think I heard you talk about this in a prior conversation.  And I really latched onto it so I wanted our listeners to hear it, too.  You had the advice, when it comes to tracking and tracking metrics and status reporting, which is, I mean, that’s the lifeblood of a project manager, right, they have to spend so much time doing that.  Your advice was keep using the fundamentals of innovation in that, too. 

Don’t keep producing the same reports and expecting all those hours that you’re putting into producing those, expecting those to be valuable.  You have to keep asking those questions and asking key stakeholders, are you getting what you need?  Is this something that you can act on?  Talk about that, because it’s a little bit different.  We like to define it upfront, and then this is your report set that you’re going to get for the next 18 months.  Enjoy it.

DAN WARD:  Right, exactly.  You know, we talk about this iterative experimental approach to our tech.  And yay, we should definitely do that.  But that same iterative experimental approach is something we could apply to our communication.  What measurements are we taking?  What measurements are we reporting?  And what measurements are really shining a light and providing insight into our progress, into our failures as well as our successes?  And that might change over time.

You know, like you said, a lot of the times we’ve set these things at the beginning of the program when we know the least about it.  And locking things down at a point in time when we know the least about the program, that doesn’t sound like a very good idea to me.  Instead, as the program goes along, as we learn more about, you know, what we’re doing; and as we learn more about our goals, our requirements, our objectives; as the technology environment changes or the threat environment changes for the military; as the personnel change, we get new people come in, old people leave; economies change; politics change; all of these changes, we need to be able to adapt.  And so we should adapt our technology as well as our processes and our metrics.

And then I would add also, we talked about speed, thrift, and simplicity.  When we have a short schedule, we basically present a smaller target to the forces of change than if we have a long timeline or a long schedule.  And that means a smaller target to the forces of change.  We need to make fewer adaptations.  We need less rework.  So that adds to some efficiencies, as well.  So one of the big reasons I like short schedules is they tend to be more stable.  But if we have a long schedule, we’ve got to be willing to adjust as new things come into play.

BILL YATES:  This was a key takeaway for me.  We need to take that approach of innovation to our reporting and to our status reporting and our normal cadence, and don’t be satisfied with it.  It’s like, every time we have a status meeting, we typically send out a report deck before that.  And we need to ask, okay, what’s the most valuable thing that we provided?  The reports that you’ve seen before you come into the meeting, what’s the one report you found no value in?  Okay, great, I’m going to scratch that.  That saves some hours for my team.

DAN WARD:  Yeah, absolutely.  So one of my favorite questions that’s sort of related to that is what if we do a little bit less?  Just the question, what if we do a little bit less?  And the nuance there is it’s a question, not a prescription, then go do less.  I’m saying let’s ask the question, what would happen if we did less?  And sometimes doing less gets us worse results.  In that case, don’t do less, do more.  Or do the same.  But oftentimes we can be like, hey, we could scale down the reporting.  We could scale down our requirements.  We could scale down whatever, and we might get better results.

And then, similarly, my formula for feedback, both for giving and receiving, this is the way I like to get feedback, and this is the way I like to give it, is tell me what was awesome, and then tell me what would make it more awesome.  Right?  I can always find something that’s awesome about somebody’s idea, even if it’s not a great idea.  Boy, that’s awesome how quickly you put that together.  What would make it more awesome is if you put a little bit more work into it.  Or, you know, hey, it was awesome you wrote this massive thing.  What would make it more awesome is if you maybe tighten it up and shorten it down a little bit.  Right?

So giving negative feedback is challenging, and nobody likes to do it.  Nobody likes to get it.  One of the big things that’s important for teams is psychological safety and this positive approach to useful feedback.  This positive approach I think goes a long way to building and maintaining psychological safety in our teams because then we come in and be like, hey, there’s something that’s really good about what you did, and here’s what could make it better.  That last part implies a mild critique, but in a positive way, like this is what would make it better.  And then you can sort of have that conversation.

Eating the Failure Cake

WENDY GROUNDS:  Dan, one last question we have.  In your book “LIFT,” you talk about a lot of examples of flight.  And prior to the Wrights, these were all failures.  How do we make people comfortable with failure?  You talk about it cultivating a specific perspective on failure.  So how can we get organizations and individuals to be more comfortable with this?

DAN WARD:  Yeah.  So that’s such a hard question, such an important one.  You know, failure is inevitable.  No matter how good you are, how smart you are, how tall or good-looking you are, you know, in some cases things just aren’t always going to work out the way we hope.  And my team has this amazing, beautiful, delicious practice that we do.  We call it “failure cakes.”  And it is what it sounds like.  You know, when something doesn’t go the way we hoped, we get a cake, and we get it from like a fancy bakery.  And we have the bakery write the words “You failed” on the cake.  And we sit around and we eat that cake while we talk about the experience.

This gives us this welcoming, playful environment to process our own failures.  It helps destigmatize our failures.  It creates an environment where on the team we would regularly say, hey, let’s try this. And it might not work out, but the worst thing that could happen is we get some cake.  So that’s tremendously encouraging.  It helps us create an environment of psychological safety so people feel free to speak up, to try stuff, to propose ideas, and to do some experiments.  And they’re delicious.  So we do these cakes in person.  During the pandemic we couldn’t get together in person, so how do we deal with that?

Well, we found that there are companies online who will mail cupcakes.  And I think I hold the record on my team of getting the most cupcakes sent to me in the mail, the most failure cupcakes.  So, you know, we didn’t get to share them with our team in person.  But on several occasions where like I would try something and it didn’t work out the way I wanted, my team sent me cupcakes in the mail to destigmatize, to take the sting out, and to sort of not celebrate the failure, because that’s not what we’re doing; to celebrate the attempt, to celebrate the willingness to try something.  Don’t you want to be a part of a team that sends you cupcakes when you fail?

Here’s the other twist, though, and one of the reasons, sort of the precursors.  In order to be able to do a failure cake, you need to be able to admit a failure.  Failure cake makes that easier to do, but it can still be a little challenging.  So in my book “LIFT” I talk about, you know, step one in studying failure is to make a list of your failures, and that is simultaneously the easiest and the hardest step because it’s not that hard to make a list, but it’s also a little bit hard to come face to face with it.

One thing that often makes that really challenging is we often discover, I don’t have any failures, per se.  I haven’t done anything that constituted a success or a failure.  You know, I went to a lot of meetings.  I read a lot of emails.  I made a bunch of PowerPoint slides.  But was any of that a failure or a success?

So in that case, when we ask people to make a list of their failures, and they can’t come up with anything, here’s what I ask them to write down.  Top of your list, “I failed to fail.”  I didn’t even fail; right?  Eat some cake about that, and then go try something that might produce an output that constitutes either a success or a failure – discrete, measurable, output you can point to.  Again, back to that definition of innovation, novelty with impact.  Something where you aim to have an impact.  And then if you don’t have the impact, hey, worst thing is you get some cake out of it.

BILL YATES:  Yeah.  That’s great.

DAN WARD:  One other variant on the failure cake is we got a great big sheet cake, we set it up in the cafeteria, and we offered free slices of cake to anybody who was walking past.  All they had to do was get a little yellow sticky and write a failure story on that sticky.  Share us your failure, we’ll give you some cake.  And we put them all up on a whiteboard.  And, wow, the conversations we had with folks.  Some of them were funny.  Some of them were poignant.  And what that did to the  culture, just even in that moment, to build a culture that destigmatizes failure, seeing everybody’s failure stories made people more likely to share their own.  And, yeah, the cake was pretty tasty, too.

Get in Touch with Dan

WENDY GROUNDS:  Dan, if our audience want to get in touch with you, what’s the best way they can reach you?

DAN WARD:  Sure.  You can visit my website, TheDanWard.com.  That’s T-H-E and then my name, Dan Ward, dot com.  I’m on Twitter and LinkedIn, generally under @thedanward.  Yeah, I would love to hear from folks.  At my website you can get downloads of free excerpts from most of my books to include audio samples, other files and little freebies that we have on the website.

BILL YATES:  That’s fantastic.  Thank you so much for sharing this with us.  There’s such a direct application to project managers.  Many of the topics we’ve talked about are things that we as project managers struggle with.  And we’re looking for fresh ideas.  We’re looking for confirmation of what our head’s telling us; right?  It’s like, okay, I need to create a new culture about failure.  My team is getting too complacent.  We need to be pushing the envelope here.  And how do I do that?  I buy cake.

DAN WARD:  There you go.  Yeah, cake.  Thank you so much for the chance to be here.  It was a delightful conversation.  I really appreciate it.  And I look forward to continuing to listen to your podcast.

Closing

WENDY GROUNDS:  That’s it for us here on Manage This.  You can visit us at Velociteach.com, where you can subscribe to this podcast and see a complete transcript of the show.  You have also just earned your free PDUs by listening to this podcast.  To claim them go to Velociteach.com.  Choose Manage This Podcast from the top of the page.  Click the button that says Claim PDUs, and click through the steps.  Until next time, keep calm and Manage This.