Almost every big idea today involves some form of technical innovation. But whether you are conceiving a new startup or a plan to advance the business model of a large corporation, don\u2019t make the common mistake of assuming you can outsource technical knowledge and direct that team without significant technical knowledge of your own.<\/p>\n
When would-be innovators or project directors lack sufficient technical knowledge, a number of things typically happen:<\/strong><\/p>\n 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.<\/p>\n The less knowledgeable director will typically select a developer for every other reason than how good his code is, like 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<\/strong>. And then execute on that platform.<\/p>\n Without knowledgeable guidance, the project may become over-engineered, with hidden scope creep, 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.<\/p>\n Good engineers pride themselves on thinking through all the facets of a project<\/strong>, all the issues a system may encounter, and also developing robust solutions to those problems. And that\u2019s a valuable trait.<\/p>\n 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\u2019s 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.<\/p>\n “The project director who lacks sufficient technical knowledge\u00a0will helplessly trust the engineers to make key strategic decisions.”<\/p><\/blockquote>\n The opposite of above, an ineffectively engineered project will lack key solutions<\/strong>.\u00a0Often they are solutions that cannot be seen on the surface, or 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\u2019t serve well for some key feature or function.<\/p>\n The unknowledgeable project director won\u2019t know. Obviously, developing virtually anything with Flash today would be a huge mistake, and even many non-developers know that. However, there are so very many other less obvious bad choices out there. And strong, popular tools that are otherwise perfectly relevant against today\u2019s technical landscape can still be poor choices for a given project.<\/p>\n When you don\u2019t 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.<\/p>\n Hidden within every technology are unique opportunities to do things better<\/strong>. And every new idea holds the risk of not aligning with the technology\u2019s 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\u2019t do well. You need to know enough to guide the team toward the technology\u2019s strengths and problem-solve the weaknesses.<\/p>\n If you are doing anything remotely innovative, when you brief the project with your dev team there comes a point in the conversation when a developer will stop you and say, \u201cThat won\u2019t work\u201d or \u201cThat will take X-time to do.\u201d Indeed, I have yet to work on a tech project in 25 years where this part of the conversation doesn\u2019t rear its head at some point.<\/p>\n If you don\u2019t have experience with the specific technology (and even related technologies), you will necessarily defer to the engineer and follow his lead<\/strong>, 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 \u201cit can\u2019t be done\u201d statement is almost never true.<\/p>\n 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 \u201ccan\u2019t be done.\u201d Fine. But a knowledgeable director will, with a few key questions, identify that hidden, incorrect assumption, and make the project suddenly \u201cpossible\u201d again<\/strong>. Further, having experience with the technology will allow you to participate in the problem-solving and brainstorming that is almost continuously necessary.<\/p>\n “Having experience with the technology will allow you to participate in the problem-solving and brainstorming that is almost continuously necessary.”<\/p><\/blockquote>\n Without that knowledge, you will quickly wear your developer\u2019s patience thin. You will lose credibility by offering off-target ideas that aren\u2019t useful. And worse, you will unwittingly drive the project toward weakness.<\/p>\n No, you don\u2019t have to be a developer, and you don\u2019t 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\u2019t. But if you want to lead very successful tech-based projects, you must develop functional, gut knowledge of the tech you\u2019ll be using.<\/p>\n <\/p>\n Fortunately, there are a few things you can do to rapidly develop this knowledge<\/strong>:<\/p>\n Ask numerous developers or creators what tools they would use and why. For web code, there are some great forums. Try GitHub<\/a> or Stack Overflow<\/a>.<\/p>\n If there is a technical expertise, there is a forum out there: robotics, plastic injection molding, tooling, everything. Reading the forums and asking questions will expose you quickly to the range and depth of the problems these specialists face.<\/p>\n Good grief, what did people do before the internet? They couldn\u2019t study or innovate as readily as you can now, surely.<\/p>\n Search YouTube and iTunesU and you will find many good overviews of various tools. Investigate repositories\u2014for 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.<\/p>\n 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, because few non-developers are willing to dive this deep. But in my experience, this step is the most useful thing you can do.<\/p>\n 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\u2019s key facets. It will allow you to be more creative. If you get stumped, don\u2019t be afraid to revisit the forums and ask your question.<\/p>\n If your team suggests a new tool mid-project, apply the above steps and study it. Make sure you\u2019re satisfied with the rationale and the solution.<\/p>\n Doing the above won\u2019t make you an expert (and that needn\u2019t be the goal). You do not have to learn to write code proficiently. Following the above guide won\u2019t get you there anyway.<\/p>\n The goal is to quickly educate you on the main differences between technologies and tools. Do this and you\u2019ll 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\u2014and you\u2019ll be more able to surf the waves of change.<\/p>\n “As your knowledge of various tools and techniques grows, you will find yourself able to draw more parallels and comparisons\u2014and you\u2019ll be more able to surf the waves of change.”<\/p><\/blockquote>\n Remember, you can\u2019t simply outsource technical knowledge and experience. You must know enough to lead.<\/strong> You don\u2019t have to be an expert, but you must develop a solid gut understanding of the tool. It\u2019s the only way you will effectively direct a team of experts with certainty and credibility.<\/p>\n <\/p>\n To find how a Hult degree can help you develop the key leadership\u00a0skills you need to stay current, download a brochure<\/a>.<\/b><\/p>\n Grow your leadership capabilities with an MBA in international business<\/a> at Hult. To learn more, take a look at our blog Leadership training: Are you learning fast enough?<\/a>, or give your career a boost with our Masters in International Business<\/a>. Download a brochure or get in touch today to find out how Hult can help you to learn about the business world, the future, and yourself.<\/p>\n","protected":false},"excerpt":{"rendered":" Almost every big idea today involves some form of technical innovation. But whether you are conceiving a new startup or a plan to advance the business model of a large…<\/p>\n","protected":false},"author":115,"featured_media":14641,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[114],"tags":[212,180,204,239],"yoast_head":"\n1. Working with the wrong developers<\/h3>\n
2. Over-engineered projects<\/h3>\n
3. Ineffectively engineered projects<\/h3>\n
4. Lacking relevant creativity<\/h3>\n
5. Most of all\u2014a tech-challenged leader is unable to direct<\/h3>\n
1. Talk to many experts in advance<\/h3>\n
2. Study the tech online<\/h3>\n
3. After doing the above, build something simple yourself<\/h3>\n
4. Stay current<\/h3>\n
\n
\n