Confidence is a wonderful thing. In fact, it is absolutely necessary when you are developing a new product idea. Without confidence you will struggle to manage teams effectively, have trouble getting others on board with your vision, or fail at solving difficult problems with effective win-win solutions. We require self confidence in order to be highly creative. The ability to project confidence externally is required to get anything meaningful accomplished when two or more people are involved.
Having high levels of confidence is fantastic, so when does it stop being a value and end up costing other people money? When does being too confident about one’s capabilities become detrimental? When does using one’s overconfidence to convince others that your way is the right way, ultimately turn into a failed solution?
As a product designer, I see a lot of failed projects, and regrettably, have even been involved in a few. They were painful experiences, to say the least, and they taught me a lot. I have seen more than a few development programs that ventured down the wrong path walk through my office door looking to be rescued. They were in serious jeopardy of ending in the junk pile. Some of these programs had experienced team members and were managed by very smart people. At a point in my career, I started to ask myself, what happened to send these programs into such a dire state? I wanted to be able to provide value to fix these programs. I wanted to be able to advise future teams of what to do and what not to do in order to increase their chances of success when developing a product.
Of course there are a lot of items that contribute to failed programs. I will address some of them in other articles. For this post, I want to delve into the issue of being overconfident and how confidence, which is so valuable, can become such a liability when it crosses the line. I have learned when to be confident that my direction is correct, knowing from my past experience that my team and I can deliver results. I also know when to acknowledge that I am in unsure territory, and I can’t in good conscience, guarantee results. Here are a five of my value bombs about confidence when developing new products.
If you haven’t done it before, you are not an expert. In fact, even if you have done it before, if you can’t comprehensibly explain it to someone else, you probably don’t really understand it well enough to be called an expert. I am always amazed in life by the mistakes I have made. You know what? It was always something that I didn’t expect because I didn’t fully understand what I was doing. We can’t know what we don’t know. Not being very familiar with the task at hand and all the potential pitfalls and problems is where we all run into trouble. In my mind, being an expert in any particular area, among other things, means you understand potential risks and know how to react if and when they occur. As an expert, others are relying on you to lead them to safety. It is a great responsibility.
Do not minimize the potential risks. No one wants that person on the team that is always pointing out the potential problems. That behavior pattern creates its own negative self-fulfilling prophecy. What I am referring to is a healthy dose of respect for what can happen if we underestimate potential problems. Unfortunately, thinking everything is just going to be fine regardless of things like physics and the laws of gravity, doesn’t make it so, at least not in my world. Overconfidence in your abilities and thinking you will succeed, can lead a team into a wall at top speed with no chance for recovery.
For example, if you plan on pushing a particular process to its limits, or expect to make something truly unique, you can expect problems. If you are not very clear of what those problems might be, then you need someone on your team that does. I am a big believer in contingency plans throughout the entire process. Contingency plans don’t mean you’re not committed to success, they mean you’re smart.
When we rock climb we use ropes. Not because we don’t expect to get to the top, but because we don’t want to die if we fall. The point being, what you don’t know can certainly be the source of future problems. It may even take a while for those problems to surface. As a consultant, the last thing I want to hear is that a client has problems with our design months or more after we completed our part.
Overconfidence leads to complacency. A successful business man, whom I did yard work for as a teenager, told me this. He was referring directly to the large tractor I was operating when he saw me whipping around the yard. He pointed out, that if I got overconfident I might disregard how dangerous that piece of machinery was and end up under it. The same holds true for product development, and especially in building and manufacturing products.
There is absolutely nothing wrong with pushing ourselves into areas where we are not experts. This is how we grow. The problem occurs when we believe that we are experts in areas where we are not. Others on our team believe that we are experts as well, and they rely on us to deliver. This can lead to missing critical issues. That can result in big problems. When developing a part or product that is unique, extra time must be allowed for the unknown to happen. If you don’t have extra time, and extra budget, be very wary of how far you stray from your core knowledge base.
Knowing is not the same as doing. I learned this the hard way a very long time ago. I remember as a kid, boldly jumping into making repairs on my car with more confidence than brains. Only to find out that I caused more damage breaking other parts in the process. I have seen this as well with people in positions of authority or represented as an expert in a specific area when they give incorrect advice. They were so confident and sure of what they were saying, had I not had previous experience in that specific area, I would have believed them. We all need to be able to trust the advice we are given by experts we rely on to guide us. There is no way we can know everything ourselves. Almost everything we need to build these days requires a team and each member to provide valuable and correct information for that program to succeed.
Managing and leading others is really hard. If you are a leader of teams, you have to manage both the team and the ultimate deliverable of that team. As the leader you have to project confidently, to your client or customer, the capabilities of your team and what they can deliver. When team members are overly confident in their abilities or don’t fully understand the risks associated with a particular task, they compromise everyone. In business, that ultimately means that someone loses money. Maybe it means that the product is delayed, fails to reach the market or the business goes under.
I get it. We all want to be valuable. We want to provide useful information and think optimistically about what we can achieve. I have a standard that I now hold myself to; if I have not done it before, or am unable to articulate the risk versus reward of any particular task, I need to fully disclose that to the team, my client or anyone else involved. I also bring someone onboard that has demonstrated knowledge and experience. Or, I need to decline to work on the program.
As a leader or team manager you need to empower your team to have the confidence to know when they can accomplish a task and when it is beyond them. This is not an easy thing to do and requires a process in place that continually reinforces this ideal. Sometimes getting in over our heads is a slippery slope, and before we know it we are committing ourselves in areas way beyond our skill set. With big dollars and tight schedules on the line, it can be very difficult to admit we don’t have the skills required, or that we need to bring in new resources, or we should completely reevaluate a part design due to potential risks of failure. This IS the type of confidence that is required. I believe we all have a responsibility to care about the outcome from our words and actions. In regard to caring about the quality of what we deliver on a daily basis, I don’t believe we can be overconfident enough!
If you are developing a hardware product, contemplate the following questions:
1) Do you have all the skill sets required to get successfully to production?
2) Do you have a good understanding of the potential program pitfalls?
3) Do you know how to solve those pitfalls and have the resources to do so?
If you would like to discuss your hardware development program and get an assessment of where you are in relation to these questions, reach out to us at www.driveninnovation.com.
