Joel Hladecek

Our guest editor Joel has over 30 years experience pioneering creative solutions and strategies in emerging mediums – from Fortune 500 interactive marketing solutions to virtual reality theme-park rides. He currently serves as the World Wide Creative Officer of EF Education First. You can read his blog at

Share this post

Tweet about this on TwitterShare on FacebookShare on LinkedInGoogle+

Know the technology or fail.

Almost every big idea today involves some form of technical innovation. But whether you are conceiving an innovative new startup or a plan to advance the business model of a large corporation, don’t make the common mistake of assuming you can outsource technical knowledge and direct that team without significant technical knowledge of your own.

When would-be innovators or project directors lack sufficient technical knowledge, a number of things typically happen:

1) Working with the wrong developers

Every developer is different. Code is like poetry. There is never one right way to do anything, not even one right language. And in this quagmire, without sufficient technical knowledge, you will struggle to determine which developer(s) will do the best job. The less knowledgeable director will typically select a developer for every other reason than how good his code is, selecting the person who articulates his thoughts best, or shows the coolest-looking demo. And while communication, passion, curiosity, etc. are indeed very important, the most important part of the evaluation is how well the developer is able to select the right tool or platform for the job, and then execute on that platform.

2) Over-engineered projects

Without knowledgeable guidance, the project may become over-engineered, with hidden scope creep (when a project grows in complexity and cost beyond the original plan), added backend features, and underlying systems that may ultimately be unnecessary. Such a situation is a problem, because every day spent in development, every new skill and resource added, increases cost and pushes out the deadline. For a startup with limited funding, that can spell doom. Good engineers pride themselves on thinking through all the facets of a project, all the issues a system may encounter, and also developing robust solutions to those problems. And that’s a valuable trait. But the project director who lacks sufficient technical knowledge and skill will find himself at a loss when the tech team explains the technical considerations and rationale behind any scope creep or changes in plan. It may be perfectly critical for the project, it may be a solution for a later version, or it may be outright unnecessary given the project’s strategic objectives. But this project director will be unable to knowledgeably rein in and guide the project scope; instead, he will helplessly trust the engineers to make those key strategic decisions.

3) Ineffectively engineered projects

The opposite of above, an ineffectively engineered project will lack key solutions, often solutions that cannot be seen on the surface, solutions that would have enabled critical, massive scaling, or future development. Or even more likely, it will be developed on a rough, proprietary, or poorly selected platform that doesn’t serve well for some key feature or function. The unknowledgeable project director won’t know. Obviously, developing virtually anything with Flash today would be a huge mistake, and even many non-developers know that, but there are so very many other less obvious bad choices out there. Strong, popular tools that are otherwise perfectly relevant against today’s technical landscape can rather be poor choices for a given project.

4) Lacking relevant creativity

When you don’t know the technology, your ability to conceptualize and help solve problems is critically limited. Well-designed and developed tech-based projects are the result of intricate relationships between hardware, software, business model, human behavior, and many other facets. Hidden within every technology are unique opportunities to do things better. And every new idea holds the risk of not aligning with the technology’s strengths and weaknesses. Understanding the subtleties of the tech will allow you to develop graceful solutions and avoid forcing a technology to do something it doesn’t do well. You need to know enough to guide the team toward the technology’s strengths and problem-solve the weaknesses.

5) Most of all—unable to direct

When you brief the project with your dev team, if you are doing anything remotely innovative, there comes a point in the conversation when a developer will stop you and say, “That won’t work” or “That will take (project-ruining span of time) to do.” Indeed, I have yet to work on a tech project in 25 years where this part of the conversation doesn’t rear its head at some point. If you don’t have experience with the specific technology (and even related technologies), you will necessarily defer to the engineer and follow his lead, because he is the obvious authority on what can and cannot be done. Without sufficient knowledge, this can result in key aspects of the project getting shelved, deadlines getting pushed, and costs rising. But over time I have learned that the old “it can’t be done” statement is almost never true. Rather, the engineer has usually had to make many perfectly natural but unspoken assumptions about numerous minute details of the project. And under those conditions, it may indeed be perfectly true that something “can’t be done”. Fine. But a knowledgeable director will, with a few key questions, identify that hidden, incorrect assumption, and make the project suddenly “possible” again. Further, having experience with the technology will allow you to participate in the problem-solving and brainstorming that is almost continuously necessary. Without that knowledge you will quickly wear your developer’s patience thin, you will lose credibility by offering off-target ideas that aren’t useful, and worse, you will unwittingly drive the project toward weakness.

You can’t cheat this process. No, you don’t have to be a developer; you don’t have to invest years in becoming a programmer or plastics expert or any other technical specialist. In fact, unless that is your dream, I strongly recommend you don’t. But if you want to lead very successful tech-based projects, you must develop functional, gut knowledge of the tech you’ll be using.

There are a few things you can do to rapidly develop this knowledge:

1) Talk to many experts in advance

Ask numerous developers or creators what tools they would use and why. For web code, there are some great forums, try GitHub or Stack Overflow. If there is a technical expertise, there is a forum out there: robotics, plastic injection molding, tooling, find it. Reading the forums and asking questions will expose you quickly to the range and depth of the problems these specialists face.

2) Study the tech online

Good grief, what did people do before the Internet? They couldn’t study or innovate as readily as you can now, surely. Search YouTube and iTunesU; you will find many good overviews of various tools. Investigate repositories—for example, for front-end web development (canvas elements), look at CodePen The Internet is truly an education if you are willing to assemble your own curriculum.

3) After doing the above, build something simple yourself

There is almost always a simple introductory project or tutorial you can do, if not from the developers of the tool, then offered by experts in the community. This is the part few project leaders bother with; few non-developers are willing to dive this deep. But in my experience, this step is the most useful thing you can do. It will give you the strongest foundation and respect. You may only scratch the surface, but going through this process will open your eyes to so many of the tool’s key facets. It will allow you to be more creative. If you get stumped, don’t be afraid to revisit the forums and ask your question.

4) Stay current

If your team suggests a new tool mid-project, apply the above steps and study it. Make sure you’re satisfied with the rationale and the solution.

Doing the above won’t make you an expert (and that needn’t be the goal). You do not have to learn to write code proficiently. Following the above guide won’t get you there anyway.

The goal is to quickly educate you on the main differences between technologies and tools. Do this and you’ll know what they are for, and what makes them unique. It will give you a basic foundation on which to be creative going forward. The more you do it, the easier it gets. As your knowledge of various tools and techniques grows, you will find yourself able to draw more parallels and comparisons; you’ll be more able to surf the waves of change.

Remember, you can’t simply outsource technical knowledge and experience. You must know enough to lead. You don’t have to be an expert, but you must develop a solid gut understanding of the tool. It’s the only way you will effectively direct a team of experts with certainty and credibility.