2013 Main Conference Talk
This four-letter word is praised publicly as something we should do often, and fast. But are we showcasing it with our clients and our colleagues? It is easy to show a refined product and a series of process sketches, but to curate and include genuine failures and not just sanitized process is just as important to build lasting relationships. This is scary to do and something our field struggles with in practice, despite the best intentions.
Documenting failure doesn’t need to be scary. I’ll share benefits of being transparent about our failures within our teams and with our clients. This won’t be 40 minutes of rote presentation. You will have a chance to pinpoint experiences of your own and will leave with an understanding on how to use these lessons to advance your projects rather than act as a blemish.
About the speaker(s)
David Farkas is a UX Designer living in Philadelphia, PA and has a passion for uncovering process and story through iterative client engagement. His experience includes work across a number of financial organizations, e-commerce platforms and a variety of business systems.
For the last 4 years, David has been part of the growing Experience Design team with EPAM, an international software design and development company. As part of the team, he also leads mentorship and growth opportunities. David embraces process and research as a tool to engage clients across all levels of a project. David is passionate about research and collaboration throughout project phases. Beyond his work as a consultant, David practices improvisational theater, a skillset he credits for much of his success in the design studio.
David Farkas: As Brad said, I’m going to be discussing the “F word,” fail. In particular failure as part of the design process.
Just some additional introduction. I want to say I have failed the last few months I’ve been preparing for this talk, thinking I was going to be either hung over, without a voice, or anything like that. In spite of karaoke’s best efforts I’m here, so I see that actually as a very nice failure, but failure nonetheless.
You can follow me on Twitter @dafark8 and the hashtag I’m going to be following today is going to be #failbtrux, “fail better UX,” so any questions, continuing the conversation. That’s what I’m going to be tracking for the coming months.
But to talk about failure, this is actually a very interesting topic for me. It’s something that I’ve been thinking about for a little over a year, starting back at MidwestUX last year, actually. I gave a presentation on interaction design through Mixology. Something that came out of that talk that was very interesting was how I share my process, how I share my failed recipes, my failed ingredients and just those lessons learned.
After a lot of reflection, I realized this was something that was not only an issue in my hobbies but in my career, as well. We talk about failure. We talk about process, but the problem is we don’t actually do anything about it. There is a lot of really nice words about it, but I haven’t actually seen failure shared in a way that is truly actionable yet.
That’s something that I really thought about, and then I came today to be able to share some of those thoughts and some of those stories. One of the first things I realized is the challenges around how we define failure.
This is the dictionary definition of failure. It’s, “To fall short or to become absent or inadequate; to be unsuccessful.” This is a list of things that we want to avoid doing. It’s a list of things that we’re taught from a very early age not to do.
We want to get a passing grade. We want to be accepted onto the sports team, all those things. Failure is something that you’re told, “If you don’t know the answer, don’t raise your hand because you don’t want to be wrong.”
If you compare that to a mistake, though, which is something that, again, from a very young age we’re taught is to blunder or to misunderstand the meaning of. Mistakes happen, though. Mistakes, we’re taught, are a part of daily life. We want to face them head on, learn from them, share them, and get stronger from them.
This is great from a personal standpoint, but when you start thinking about a professional standpoint, mistakes and failures tend to blend. We actually tend to define the two incorrectly.
Because we’re talking about failure in a professional sense today, I want to offer the definition that failure is a time of personal discomfort, a bad day, or even something that’s an instance or event where things could have gone differently than planned or went differently than planned.
With this definition of failure, this is how we’re going to think about failure in a professional sense, but it’s still not the only type of failure. There are many types of failures and many ways to fail.
There are catastrophic failures. There are embarrassing failures, and anyone who went to karaoke, I’m waiting for those stories still.
There are social failures which could be a foot in mouth experience or a slap in face experience.
David: Brad, thank you for letting me put this in and if you haven’t slapped Brad yet, I highly, highly suggest it. [laughs]
There are also shocking failures. That video will be online. Don’t worry. There are shocking failures. This is actually the Schuylkill River path up in Philadelphia. People go there for walks, bike rides, picnics, whatever. You don’t really see vehicles there.
This is a minivan trying to get through the narrow side of an underpass. Then, if you notice the dog there, I like to think he’s the only spectator and not the actual photographer.
David: There are also intentional failures. These are a very interesting type of failures. It’s not what we’re going to focus on today, but this is actually something I’ve found working with a lot of developers where they write testing scripts in order to intentionally watch their code fail. The purpose of that is to debug their code, find the problems in the application, everything else.
This is a really good outcome of failure. It’s when you actually strive to fail. I think it’s something we all need to keep in the back of our heads of how we can use failure as a positive outcome.
But the failures that I really want to talk about are the day to day failures. These aren’t about life and death. These aren’t about bankruptcy. These are the challenges we face every day where there’s some sort of room for improvement, either personal or professional.
Inside these day to day failures there are still many ways to fail. There are personal failures, the kind that we internalize, the kind that we hold on to ourselves and just sort of get ulcers because of.
There are team failures, the kind that we’re probably most familiar with, where we go into closed door meetings and have project closes and we debrief on what went wrong or how we could have avoided certain challenges.
There are public failures, the kind that we share with total strangers. If you’re a sports team or anything like that. You might not be a player, but you share that loss with the fans. You share that loss with the players.
One similarity all these failures have is they’re all emotional in some way, shape, or form. Emotion is a huge part of failure. What we have to realize is that’s the nature of the beast and we really just have to learn how to use that emotion, use that failure to grow from it.
All failures really affect us individually, but we need to just get stronger about sharing them. The first way I’d like to think about doing that is to not think of them as failures, but to think of them as experiences. Randy Pausch, the author of “The Last Lecture,” once said, “Experience is what you get when you didn’t get what you want.”
One possible interpretation of this is experience is what you get when you fail. Experience isn’t a scary thing. Experience can really be associated to mistakes, which we already talked about, whereas failure is something you want to avoid.
Experiences are part of life and they don’t have the same stigma that failures have. If we can start thinking about that, that we want to have more experiences, more conversations about that, then we can learn to overcome these failures in a better way.
This is something that I find true in design education, where we’re constantly talking about design process and the need to fail often, fail fast, but we often show it in a very sanitized or sterile way.
One thing I’ve learned is that we like to show process, we like to talk about process, and relate process as failure, but they really are two different things. Process is when we take a series of sketches. We scan them in. We white balance them, annotate them really beautifully to tell a compelling story about how we got to a design decision. That’s not failure.
What failure is is the raw experiences, the piles of sketches that we have that went straight into the waste bin. The piles of incomplete sketches that never got thought through. The times when we had to fire clients or had sales pitches get away from us. Broken prototypes, broken code; these are raw experiences, these are raw failures.
This is a scary thing to think about. What I want to do to start is by saying that I have failed and I have had experiences. These are some of the experiences I’ve had, and those of you that know me probably know some of these stories.
Arguments with clients where I was driving with them to contextual inquiries and we kept getting lost every five minutes because they wouldn’t check the GPS.
Times where I just expected the worst, where I was in a position where I wasn’t quite sure how to push myself, and because of that I wasn’t finding the best design solution.
Times where I really just let go and lost track of a meeting or got away from a presentation.
What we have to remember, and this is something that I really learned when I was expecting the worst and not pushing myself. That’s one of the bigger personal failures for me. Is that failure ultimately leads to success.
This is a pretty known Thomas Edison quote. “I’ve not failed a thousand times. I’ve successfully discovered a thousand ways not to make a light bulb.” We’ve all heard this, but what’s interesting about this quote is this is a version of sterilized process or sanitized process. Edison’s talking about the need to fail. He’s talking about the need to mess up. The old adage, “you have to crack a few eggs to make an omelet.”
But what he’s not doing is he’s not showing the process. He’s not showing all the mistakes he’s made. No where have I ever heard of Edison opening up the doors to a warehouse and a thousand pieces of glass and filament pour out as all the ways that he’s learned during this process.
If you compare that to the movie “Objectified,” where you have a scene very early on about the OXO grips. There’s actually parts there where they open up cardboard boxes full of models, of foam models, full of failed designs that ultimately led to the design of the OXO good grips.
This is industrial design, a process where you have extremely high tooling costs, extremely high manufacturing costs. You really want to make sure you have the right solution before sending this out in the world to become a physical object.
They take the time. They take the humility almost to show the process, to show the failures on film in a very public way. This is something done for design, so it’s our field, but it’s done in industrial design. But there’s no reason we can’t do it for content or for interaction design or for aesthetics, and show all of the versions of the PSDs that we went through to get there. And show why we got there. Show that evolution.
All too often, we want to show just the two or three main screens that got us to the final design, but a lot is lost in communication there.
Ultimately, what we have to remember is that failure or experience is a great thing. But more important than failure, we need to share these failures. Sharing is the most important part of this, being public about it, and that’s something we need to get better about embracing.
What I want to do next is I want to share a few stories of mine. Stories that I’ve either experienced or observed pretty directly. This is because I can’t possibly experience every possible failure. No one in this room can experience every way to fail. We learn from other people’s mistakes so that we don’t make them or we learn from other people’s mistakes to make new ones in entirely different horrible ways.
I’m going to share five stories of what I’ve learned, what happened, what I learned and most importantly, how I think we can teach this to each other, so that we don’t make the same mistake twice.
First lesson I want to share is about how failure helps us learn from others. This is a story about broken down or failed communication. A few years ago, I was working on a very large project where it was a rotating team, just because of attrition, people moving through the company, the designers were moving through over a course of five or six years.
The client team had been around for the entire duration, though, and they had a very large amount of institutional knowledge. The big challenge was when I inherited this project, I started making design recommendations that were counter to what the designer made before me, what the client had asked for a few years ago or even a year ago.
But there was no way to know this. There was very little documentation tracing what the decisions were. There was very little documentation for what the research was done a year ago and why we went down a certain design path.
The biggest lesson I took away here is to document early and often. I’m not saying spec docs if you’re in a Lean or Agile space, but what I’m saying is document decisions. Trace your rationale for getting somewhere. If the navigation moves from a top navigation to a left navigation, document when that happened, who said that.
The most important part is how we want to teach this. I think the only way this can really be drilled in is through exercises as a team. Look at projects that were more successful. Look at projects that might have had a little bit more challenges. Look and see what type of traceability there was between the decisions as they were made.
Ask people to understand or uncover what those decisions were after the fact, from people from other projects. You’ll see that projects that have good traceability, you’re able to understand why the navigation or why the research moves in a certain that it does. Projects that don’t have that are a little harder to communicate, a little harder to have knowledge transfer over time.
Next, I want to talk about humility. This is a much more personal story for me. This is actually a time where I completely dropped the ball with a client presentation. If you were in Craig’s presentation just before mine, you’ve heard of actually a similar story, which is interesting.
But what really happened to me was I was presenting wireframes to a client that I had been working with for well over a year and a half. We had a handful of projects with them. I presented wireframes early in the week, and I was back later that week to present updates to the work flow.
For whatever reason, I didn’t really look around the room and digest the fact that there were only two familiar faces in the room, despite the fact that this was half way through the project.
I jumped right in to talk about what the updates were made and how that affects the work flow. I didn’t introduce myself. I didn’t introduce the project. I didn’t introduce what wire frames were and why they’re a lower fidelity than final aesthetics.
It shouldn’t have been a surprise to me that I got about two minutes in and I was interrupted with all those questions, including being asked who I was and what my relationship to the client was. This really took me by surprise.
Sort of went back and chewed on it for a while, but the one thing I really learned is that we have to assume nothing. To treat every presentation like it’s somebody’s first, and that we really need to take the time to prepare and review in our work.
All too often, we are designing up until the last minute, up until the presentation or even a half hour or hour before the presentation. What we need to remember or what we need to do is to build in six hours a day to really talk about that story, figure out what that story we want is to tell. In that way, we can make it about the client, make it about the audience and not make it about what we’re talking about.
Ultimately, we’re trying to sell our work, sell ourselves, sell a design solution and that never stops. The only way we can really embrace that is by remembering that we need to always introduce what we’re doing to our audience. We can’t assume that they’re on our level of understanding our vocabulary or design or anything like that.
The third story is actually not one that I’ve had direct involvement with, but it’s something about Kickstarter, which I’m sure many of us are somehow familiar with. Either we supported something or we followed a few, the pebble watch or any of those.
What’s interesting about Kickstarter is about a year ago, they got a lot of flack for not making it publicly available what their failures were or what the failed Kickstarter projects were. It’s very difficult actually on any search engine to find a failed Kickstarter project. It’s very difficult on their website to find a failed project.
What’s interesting is Kickstarter finally fessed up and they said, “You know what? You’re right. When a project fails, we actually put a line of code make it harder for search engines to find it. To make it harder for it surface on our own site. The reason we do this is we don’t that product to be negatively impacted by the fact that they failed with us. We still want to give them a chance with other crowd sourcing, crowd funding options or any other way to get the funding they need to be successful.
This sounds really nice. This sounds really altruistic, that they were looking out for their customers. Again, no involvement with this, so I don’t what the true motivations were. I only have my interpretations.
But the lesson I took away from this is that you need to be transparent. You need to be honest about your motivations.
The reason Kickstarter got flak for this was because they didn’t come up at the beginning and say, “This is what we’re doing and why.” They had tried to brush it under the rug and play it off as no big deal, really.
The big lesson here is that we need an environment where we can play devil’s advocate. Devil’s advocate is really the business equivalent of saying, “I don’t mean to be rude, but…” Anything you say after devil’s advocate, you can probably get away with within certain limitations there.
But what it means to play devil’s advocate is you’re really trying to poke holes in the solution. You’re trying to poke holes in the answer. You want to make sure that things are thought through, and it’s not just because of the emotional or knee jerk reaction why a decision is being made. Especially a decision as large as it would be for an organization like Kickstarter.
The next story I want to share is one about process. This is actually a more business related story. There have been a few relationships over the years that have ended prematurely. Either the client has asked to terminate the project or we realized that the goals didn’t align with our own.
But in all these cases, there’s two that stick out in mind in particular to me. That they both failed because we weren’t clear about what our process was. We weren’t clear about the deliverables we were giving. We weren’t clear about the solutions that we were going to provide or the results that it would give to the client.
A lot of this happens because we weren’t clear about what their concerns were or what we would deliver to them. We weren’t clear about their understanding of our language. This again, it goes back to having a shared language. Talking in the client’s language and using their vocabulary.
We were trying to be sneaky in some cases or we were trying to force things through. The big risk here is that you don’t have a shared understanding. You don’t know what is being said, and you think the client understands you, but really they’re just trying to smile and nod, because they think you’re going to give them a great product, but they’re expecting something totally different.
This is where we need to build an environment of trust. This is different from playing devil’s advocate, where devil’s advocate is all about poking holes. An environment of trust is trying to make sure that everyone has the strongest knowledge, the strongest information they need to get the project done, to get the task completed.
This is asking the hard questions like, “Did you understand what a wireframe is?” or “What do you think a wireframe is?” Asking people to define the terms that you toss out there in their own language, to make sure that what they’re saying echoes with your own mental model of what these words are.
The last story I want to share is one story about consistency. This is actually a project that I’m still completing with, and it’s a story about failed process. I was brought in on this project and we’re working on a few different very large pieces of the work flow. I went away to work on a few other projects, and came back and was asked to look at different parts of the work flow.
I didn’t really codify my process. I didn’t really standardize what my solutions were, because it was, in my mind, a very brief experience. The challenge here was then that I was designing different solutions for the same problem within a single project.
The lesson I took away from this is not to skimp on the process, but the more important lesson is to be a pain and to want to shadow and want to learn with people of other verticals. I work with a lot of developers.
One of things I found was after I did the initial work flows, I went away but I would ask every few days, “How’s the work flow for the checkout process? How’s the work flow for the purchase process going?” They’d say, “It’s in the middle of a dev cycle. There’s not really a lot to show.”
If you’re designers, don’t believe that. What we have to do is we need to shadow with each other, developers and designers, content strategists and everything else, IAs. We need to understand what goes into our work, so that when we get the, “Oh, don’t worry about it,” we can push back and say, “Just show me what you have anyways.”
The biggest challenge I face was we didn’t have clear communication of where we were in the cycle. Because of that, we didn’t have clear understanding of what was going into those roles.
This is five examples, and that last one especially about process is something I’m still working on. But these five examples are by no way all inclusive of every possible way to fail. There is a bit of a template, though, and what I’d like if for this to be everyone else’s turn now, to think about a failure you’ve had. Think about an experience, so that we can share these and reflect on these.
If you’re taking sketch notes or if you’re on a computer, you can grab a blank screen and a pencil or pen. This is the group participation part.
In about three to five minutes, if everyone can write the experience type that you had. That’s the one or two word tag. Describe what the experience was. Talk about the lessons you took away. Then lastly, just one or two sentences about how you want to teach this to other people. How you think this can be imparted so that other people can avoid this.
We’ll take about three to five minutes to write the stories. If everyone wants to look up when you’re done or if you have any questions, just let me know in the meantime.
You had an embarrassing failure at karaoke, anyone?
One other quick thing. Don’t violate your NDAs. Feel free to change client names or anything like that. I don’t anyone to get in trouble when we get to the share portion.
An example of how you can teach? Yeah. That’s something like with the story of we had failed communication, and we had no understanding of what the institutional knowledge was. The teach there really in this example was we want to go through exercises of stories where there’s good traceability of decisions made and bad traceability. By going through an exercise like that, you see the value for having that understanding or having that level of communication.
I’m seeing a lot of people start to look up. If you’re not done writing yet, don’t worry. There’ll be time to finish before fully sharing this to the larger audience.
What I’d like next is for everyone to turn to the person next to you. Introduce yourselves if you haven’t met yet during the conference, and share your stories with each other. In particular, share what the failure was and how you think you can learn from that experience or teach that experience. If you had a similar story or not a similar story and how you think there might be some overlap.
There’s social lubricant if anyone needs…
David: That works pretty well. All right. I don’t want to stop any conversations short, but I definitely encourage everyone to continue these conversations after the session. What I want to ask is how was this experience? How did you feel about going through this? If there are any volunteers who want to either share what their failure was or how they felt going through this process.
If you can run the mics to them, because I know for the podcasts. Any? Yes, Amy?
Amy: I went in with a bit of a “trust me, I’m the expert” attitude. Unfortunately, I had a boss who was the vice president of product management, who also was new and had gone in with a similar attitude. We failed pretty spectacularly almost from the get go.
It’s not difficult for me to talk about this at this point, because it’s been long enough and also because I had an awesome opportunity at a different job to go in and do all the things right that I had done wrong at the first job. I actually enjoy talking about it, because I learned so much from it.
What I really learned was listen first. Listen first, share quickly and be sensitive to your audience. Don’t be tone deaf to your audience. It’s real easy to do that, especially when you’re charting new territory.
Anyone else want to share their thoughts on either their failure or the experience of sharing and going through that?
Audience Member: I had a similar issue, where I think I was not particularly aware of what it was that my audience was expecting to hear. I learned the same thing, but mine was much more recent and I would say that I hung on to a little bit of a inner hurt about how it all played out.
But actually sharing it, I find, and putting it into the context that you recommended kind of lanced that lingering irritation. I actually feel a lot better about that, so thank you.
David: So we have fun and therapy.
David: Whitney, did I see your hand?
Whitney: I was working on a project for redesign of a major magazine. I was subcontracting through the agency that had gotten the gig. I was only given two weeks to get all of my work done. As I was telling these ladies, kind of a zealot about research first.
I thought there’s no way I can do all the stakeholder research and user research and a set of wireframes in these two weeks. I had watched very recently a UIE webinar on ad hoc personas and how to conduct a stakeholder work session to tease out all of the knowledge about the customers that exist within the four walls of the organization already.
I was so proud of myself. I was going to try this new technique out. I spent all this time planning it, and I had said that I needed the key stakeholders in the room and they had set aside five hours of their day to allow me to do this.
No one from the agency that I was working with was there. There were 12 of them in the room, including the editor in chief of the magazine, who stayed with us the entire five hours. I conducted these four activities, and when I was done, I had so much that I had done to build consensus about what we were going to do together.
I was buzzing. I wrote this long email on the way home to my agency boss, the person who’s paying me, about how awesome I was and how much great work I had done.
The next morning I got a call from him. Earlier that morning, he had gotten a call from the editor in chief because she was furious. She had not shown it for the entire five hours that she had been there, but it turns out that the people that were in the room were low level developers and designers, and I had been doing consensus building exercises acting as though everyone in the room’s opinion was equal. She had been outvoted on a lot of issues.
I hadn’t really taken the time to discover for myself who was in the room and who I was dealing with. Every outcome that I had gotten from that day had been invalid, and I wasted all those people’s time. It was horrifying. I can only laugh at it now because it was just such a spectacular failure.
David: No, thank you.
Anyone else? Time for one more before we continue.
Came time for my portion of the thing. I got up, whiteboarding and how to know your users and how to really know your users and you are not the user, but your user is your user.
David: I was fired on the spot by the client.
David: Anyway, the lesson I learned from that was absolutely get the vocabulary right from the beginning.
Joe, thanks guys. I think I heard two main themes coming out of what was shared there before that share there. It’s fun when you share failures once you’ve accepted that it’s something you can learn from. It’s therapeutic, so thank you all for being my therapy session today.
There’s a lot to be said about understanding the organization you’re going into and doing your homework beforehand. Just like no two users are the same, no two client is the same.
Just one other quick fun story about failure is the Maker’s Mark I have done here. Joe actually reminded me of this. About six months ago, Maker’s Mark claimed they were going to start diluting their beverage because of expected shortages. Then they got horrible flak from the community saying, “We don’t want watered down booze.”
This actually is collector’s item whiskey if anyone wants to drink a piece of history. I need to get another bottle.
But going through this exercise, what I hope everyone took away from it is some of the value of experience. The value of failing, learning what not to do, how to get better at our craft and more importantly, the value of sharing our experiences. It’s therapeutic. It’s fun. It’s self-vindicating in ways.
Ultimately, what we have to remember is failure can be very cheap. This is one of the big arguments for Agile and Lean compared to waterfall is how failing early, failing fast can be very efficient in an organization.
There’s certainly a lot to be said about failing in large organizations where the cost can be absorbed compared to startups or smaller teams, but failure doesn’t always have to be catastrophic.
That’s one thing I hope that we’re able to take away today. Failure doesn’t have to be the end of the world. It doesn’t have to be an entire project blew up in your face. It can be a meeting. It can be a presentation. It can be a workshop. Failures on their own are opportunities to lessons.
There’s a bit of a distinction here between failing and screwing up, where screwing up can be very expensive and screwing up can cost you a lot of time or a lot of money, because that’s almost dedicated and you’re trying to screw up.
But failing happens accidentally. It’s part of the learning process. It’s part of becoming the best designers. Failing isn’t something we’re very going to be able to avoid. Failing is actually something that we want to do, but what we want to do is learn how to fail better.
I want to give you a minute to read this quote.
David: Jonah Lehrer’s an author and journalist. He was guilty of fabricating facts, lying, plagiarism, all the seven deadly sins a journalist could probably commit. He had a very interesting opportunity to apologize at the Knight Foundation. His entire open letter’s actually published on the web, and I encourage everyone to read it.
But what’s very interesting to take away from it is the idea that he needs to apologize in public. For him to just apologize to his bosses, his family, his friends and the people that he might have written about, that’s private. There’s really no way that he’s going to grow from it.
But by holding himself publicly accountable, everyone sees what he did. Everyone can learn with him. Everyone can grow with him. He knows now not to do this again, because he knows what it’s like to stand in front of the audience and say this.
Explanations can’t undo the failure. In the case of Joe’s story, he couldn’t suddenly turn back time or Whitney’s story, turn back time and start the meeting over and be more sensitive to context. But what it allows is opportunities to fail better in a different way.
I’m sure you guys have had more mistakes. I’m calling you guys out, because I know I can. To fail in new ways. To fail in better ways. The only way we can really do this is to keep this going. Keep this conversation going and to take it home with us.
The most important part about this list here is that we need to write about failure and talk about failure more. I want to provide a venue for everyone to do this. Actually, it was mentioned during the exercise that it would be great to have a blog or something to share these stories in. We actually now have the failbetterux.tumblr. It’s not animated GIFs of cats, I’m sorry, yet.
There is a review process currently, which is me, so as long as it’s not an animated GIF of a cat, it’ll probably go through.
But what I’d like is the stories you wrote down today. Start by going to the site, submit a post. It follows the same format, although it’s an open form, so if you wanted to change the format or anything else there, go right ahead. Over time, as you think of new stories or as you experience new stories, add these to the list.
I want this to be a public repository, where people can go and get lessons learned and people newer to the field can start to understand what some of the challenges were that we’ve all shared. As we’re facing new challenges, we can see if someone else has had a similar experience and learn from that as well.
What I want us all to remember is failure is a part of life. I had two poop jokes in this presentation. If we don’t call it failure, we call it experience. It’s something we can all embrace a lot more. We need to discuss these experiences, not only internally as project teams but publicly with our clients and as a community.
We need to remember to fail often and fast, because failure can be very cheap.
The list of resources I have just putting together the talk. I’m going to post the slides, so don’t worry about writing these all down. It’s all probably illegible.
But what I want to leave you with is a quote from Niels Bohr. “An expert is a man who has made all the mistakes which can be made in a very narrow field.”
Our field is ever expanding. We’re ever getting more stake, more buy in, and what we need to do is we need to embrace the fact with that ever growing responsibility, there’s going to be a growing opportunity to fail. A growing opportunity to learn, and a growing opportunity to just succeed overall.
But on the road to doing that, we will have those hurdles and we will hit those road bumps. We need to expect them and we need to look forward to them and not shy away from them.
I want to thank everyone for letting me share some of my stories. We do have books for anyone who shared a story. If there are any questions, we have some time for that.