What really stifles innovation?

As always, not going to bury the lead.  What stifles innovation? Bureaucracy. Meetings with ego-driven people that need to hear themselves pontificate about points that have already been discussed, decided on, and moved on from. Documents upon documents to identify every minor point to make sure there is no potential lawsuit. Risk aversion management that prevents people from moving without 4 levels of approval to prevent a single person getting blamed, so you can't fire everyone. Creation of slide decks over and over again that could have been created in a working prototype instead.

Now, I always try to approach a problem with a solution. So here is the ultimate solution.

Trust your employees

I know it is a huge risk to trust an employee to do the right thing. If they don't then you hired the wrong employee. To allow them the space to learn and grow. To align them with actual goals they believe in, not one's you forced down their throat. You hire people because they are smart and you believe they can do the job. SO LET THEM DO IT. We all have down time, down days, and we all fail. I hate when people say, "We can't afford to fail. There is too much at stake." There is ALWAYS too much at stake. That is business. You don't need to say that your case is different. Allow your employees to be creative and come up with solutions that you hired them for.

Failure is not a death sentence

You will fail. Having 20 meetings to try and prevent it may actually be the thing that is causing it. You are taking development time away by trying to understand development. If you want to understand development, go to a coding bootcamp. There are so many moving parts in development, you are not going to learn everything in a week. You won't know deployment strategies, build steps, coding practices, design patterns, and many more things. Why? Because that is what development does. As a developer, we don't try to build timelines, plan resource management, or build presentations. We code. We fail at coding. We fix it. We code some more.

I was going to be a doctor. I specifically wanted to be an ophthalmologist since I was around 8 or 9 years old. I started playing with computers around that time too. I went to college, even was pre-med for a while and a good friend of mine asked me why I was in computer science. I changed majors that week. Here is what I learned, if I failed as a software developer, I identify the problem and come back and fix it the next day. If I fail as a doctor, I apologize to the family. It is inevitable. I don't want to do that, so here I am being a software developer.

Agile is not always the answer

I know, I'm a huge agile advocate. However, that is the term, "agile", a definition: able to move quickly and easily. That means you should be able to move quickly and easily. Not slowly and painfully. In some projects, they are so simple, that you don't need a bunch of insane process to build something. Do what is necessary. Start with NOTHING and add on. Don't start with EVERYTHING and strip away. There are so many details to consider. The first is, what are you trying to solve? If you aren't solving something, then why are you spending your time? In some cases, you may be solving boredom for your clients (90% of content on YouTube). Think of what you are trying to solve. Then start thinking of how you are going to solve it. It really is that easy.

Egos kill innovation and productivity

If I could track the amount of money spent in meetings that I have attended with certain people not contributing at all, companies would be in awe. Imagine if you have a creative director, 3 developers, a tester, a program manager, a product manager, a designer in an hour meeting and only the CD and PM talk.  How much money was wasted, not including the time to context-shift back to coding for the developers. You don't need a big audience to make a decision, you only need the right people.

So stop spending weeks on slide decks, scheduling meetings to talk about the next meeting, and understand what your actual problem you are solving is. Then start moving forward. However, none of that matters if you don't trust your employees. Trust them to do the right thing, they will often surprise you. I've said this before, but apparently the world wasn't listening then.

Now go build something amazing!