Key Words: Engineering Excellence (E2) is a platform for producing maximum engineering accuracy and performance. Combinatorial Innovation is about different innovations working together than a single technology. Engineering Process is a series of steps that guides engineering teams as they solve problems.

The design process is iterative, meaning that engineers repeat the steps as often as needed, making improvements along the way as they learn from failure. Innovative Engineer is a category of engineers with the following seven certain habits:

1. They earn autonomy at work.
2. They think big and start small.
3. They connect dots others miss.
4. They are good at influencing.
5. They are great at saying “no.”
6. They are motivated intrinsically.
7. They move faster than most.

Social loafing or motivation loss is the reduced individual effort observed when people work in groups compared to when they work alone.

Abstract: This article is about pursuing Engineering Excellence (E2). In this pursuit, it is required to understand a series of vital matters, including technical and contractual issues, from the engineering perspective. All of the above must be led by strong leadership and with project ownership, role-related knowledge, and individual uniqueness. The pursuit of E2 is required to establish a specific culture and strategy, discover the right talents, and establish the necessary communication and Innovation within the engineering field.

E2 is a platform for applying principles to invent, design, analyze, build and test machines, equipment, systems, structures, and materials, to fulfill objectives and requirements while considering the limitations imposed by practicality, regulation, safety, and cost. At the same time, E2 is trying to achieve engineering accuracy and performance.

E2 is backed up by the necessity to commence and deliver an engineering project based not only on engineering best practices, utmost sincerity, and collective enlightenment but also leadership and ownership. E2 makes things from scratch while trying to rethink much that management follows as a convention. It is noticeable that many people are currently dealing with a mess of company politics, backscratching, miscommunication, and contractual misinterpretations during the management of engineering projects. Today’s engineering managers lack loyalty to the leadership, a meaningful hard-working self-ethic, self-mission, and project ownership. Furthermore, the engineers’ specialization in some professional regions and duties leads to a misunderstanding of the project’s conceptualization in terms of the interface and integration of its various stages of development, mobilization of the necessary resources, and implementation of a time-consuming yet practical planning process.

The lack of engineering experience to handle errors or difficulties on tough engineering challenges in terms of compliance with standards and contractual requirements, perform damage control to existing problems, handle demanding schedules, or consolidate effective cohesion on intricacies and politics among team members and stakeholders are all part of the day-to-day issues that engineers must deal with. In the 21st century, engineers should reinvent themselves and be more relevant to their engineering commitments as owners of the problem and its solutions instead of spending their valuable time on senseless emails, overspending because of subcontracting, chasing impractical schedule dates, and not focusing on getting total output with results. Engineers should be able to commence an engineering project and turn it into a successful deliverable according to the agreed technical provisions and the user’s identified requirements. This approach is the only way to take a big idea and turn it into an enormous product. E2 requires geeky inclinations which run against the prevailing attitudes of the time and the establishment. It seems that engineers currently use a more cliché format to handle their projects, and I believe very unsuccessfully. The principle behind E2 is about utmost sincerity and about pursuing “collective enlightenment” while demonstrating leadership and ownership of the problem and its solution. I believe that the moral character of the engineers or those who lead them has declined.

E2 requires that each Engineer should master complex engineering concepts during actual business plans. The mentality of the engineers that are committed to E2 should be that of a samurai. Specifically, the engineers would instead commit “seppuku” than fail. For E2 engineers, the word “no” should not exist. Everybody should apply the DO or Die principle, but don’t give up. The E2 engineers should expect that attitude from everyone around them should come out from the engineering meetings with a disgusted look. E2 should be planned and prepared to offer exciting services directly to the project’s deliverable and encourage the engineering team to outperform capacity and Innovation. E2 engineers should not rely on transferring orders, requests, or instructions only. Instead, they should be able to challenge the design and development of every contractual deliverable requirement according to the deliverable’s technical provisions but without making the engineers that they report to them unproductive. Although the engineering industry has tons of money, yet has a lot of inefficiencies. Today, we have engineers and engineering managers who are paid richly, yet some of them are dumb or insufficient, or ineffective. They are not interested in providing E2 or value-added services to their highly priced deliverable or performance to motivate the engineers reporting to them to enhance their company’s brand name. It is a fact that a lot of engineering departments copied what everyone else did. If everyone ran a bloody cliff, they’d run right off a cliff with them. Engineering powerhouses can renovate themselves without needing some significant infrastructure improvement to do things with it. It is just an entry in a database to make things better, more reliable, and more efficient.

E2 engineers must show a good track record and an innate ability to read the efficiency of engineering planning and challenge engineering design from inception until the closeout of the final design. E2 engineers must exhibit a deep insight into human nature to help their companies pull off exceptional engineering deliverables along with engineering feats. Additionally, we should build these engineers like a tank. They should have a level of stamina and an ability to deal with classes of stress that perhaps are very unusual in everyday mission tasks. E2 engineers must be brilliant, driven people with a “huge ego.” E2 requires that engineers, besides being theoretical and managerial, should also get their hands dirty. For instance, engineers talk about systems engineering but not about energy systems and engineering interface and integration. Really how many engineers take software and electricity and use it to control energy? This approach is computing combined with power electronics.

Every Silicon Valley start-up company hires a bunch of young, hungry engineers and figures things out as they go along. However, the most important is that engineers should implement the realization of implementing deliverables on time, in accordance with the contractual requirements, and along with value-added services.

E2 engineers, when they are dealing with their subordinate staff, should approach them with the mantra: “I don’t care what you think, “but this is what we should do.” E2 engineers must listen, ask good questions, have a strong will, be fast on their feet, and get to the bottom of things. E2 engineers must be hard-core and grow up in a challenging culture and circumstances. They have to become very tough to thrive and conquer the world. If any difficulty appears on the horizon, engineers must always address their engineering right away after a failure or a problem and encourage them to get back to work and perform their best. They should make sure that they are not freak-out. That communication approach will most definitely will chill-out everyone and will cause them to start to focus on figuring out what just happened and how to fix it. This approach is critical because of their pride as engineers, and their hopes and dreams are on the line. E2 engineers’ ability to stay focused during a crisis is one of the main advantages of this cast of technical people. The harder it gets, the better he gets.

E2 engineers’ style is a demanding commitment that can only flourish when there are highly individual and company aspirations in the internal and external arenas. Elon Musk (the founder and owner of Tesla, Space X, and Solar City) is an excellent example of a demanding manager. Space X constantly pushes to advance its technology and change the economics of the industry. Specifically, Space X founder Elon Musk simply wants to lower the cost of deploying satellites and resupplying the space station. He also wants to reduce the cost of launches so that it becomes economical and practical to fly thousands upon thousands of supply trips to Mars and start a colony.

On the other hand, it seems that the rest of the space industry has made space dull. Another essential factor for E2 engineers is to “have an obvious vision.” Specifically, E2 engineers must know exactly “what they want to do.” On that note, E2 managers must hypnotize you. By giving you their crazy eye, then should be yes, we can resolve all the red flags and meet the agreed schedule dates.

Dependency on outsourcing services and products is a weakness. To save money, an engineer should plan to buy as little as possible within his department or company. Currently, companies believe that reinventing the wheel for every computer, machine, power distribution, or specific service introduces more chances for error and, in general, is a waste of time. By eliminating outsourcing and dependency, I believe you can create products and services that outperform commercial ones. When that happens, they become the de-facto hardware or service. In this way, as well as another differential cost way, E2 engineers, can manage substantial cost reduction.

E2 engineers must master particular management and leadership techniques for which they would become famous and perhaps infamous. During your professional journey as an engineer, it is crucial to learn to pick things up on the job. Although engineers initially rely on textbooks to form the bulk of their engineering management and leadership knowledge, I firmly believe that textbook knowledge is a different animal when you compare it with hands-on experience knowledge.

Regarding time, E2 engineers must set more aggressive delivery targets for challenging to make products and services than any engineer in history. E2 engineers and their technical staff must be recognizable for their daring character in jarring aspects. Also, they must be optimistic. They must always pick the most aggressive schedule imaginable, assuming everything goes right, and then accelerate it by taking everyone can work hard and efficiently. By applying this approach, there’re times that E2 engineers may look like downright liars with regard to a deliverable. Yet, it is necessary to put things in a higher hierarchy to get things done, even if that means you employ extra pressure on yourself and your team respectively. Thus, in the 21st century, the engineering platform requires special individual abilities and work ethics. E2 engineers must do things fast. For example, they must pee quickly, like a firehose, three seconds and out. They must be authentically in a hurry. However, at this point, let me make an additional remark. E2 engineers should not set impossible tasks. Impossible tasks can be demotivating. For example, you don’t want to tell people to go through a wall by banging their heads against it. Yet, the engineering approach to the tasks must be aggressive and well substantiated from the engineering point of view. Of course, there are times that E2 engineers require to do some re-calibration to be a little more realistic.

I believe you don’t want a timeline where, based on everything you know, the schedule should be an unknown “X,” and you execute towards that, but with the understanding that there will be all sorts of things you don’t know about that will push the date beyond that. It doesn’t mean that you shouldn’t have tried to aim for that date from the beginning because aiming for something else would have been an arbitrary time increase. It is different from saying, “Well, what do you promise people?” Because you want to try to promise people something that includes schedule margin. But to achieve the externally promised schedule, you’ve got to have an internal plan that’s more aggressive than that. Sometimes you still miss the exterior program. Dealing with epic aggressive schedules and expectations will require engineers with E2 must develop a variety of survival techniques. Thus, one approach is to ask your engineers for highly detailed proposals and task(s) oriented daily planning for how we will accomplish a project. The engineers with E2 have learned to break the time needed to accomplish something down into day-by-day and hour-by-hour forecasts and sometimes even minute-by-minute countdowns, but never into months or weeks. For them, any fallout from missed schedules must have severe consequences.

To maximize the power of the individual, Engineers must master the art of getting the most out of them. Engineers must use managerial nuance to meet their deadlines. A typical manager may set the deadline for his engineering team; I guide my engineers into undertaking ownership of their delivery dates. For example, I don’t say, “you have to do this by Friday at 2 pm. Can you do it?” “I need the impossible done by Friday at 2 pm. Can you do it?” If the Engineer responds “yes” to me, then that means you are not working hard because I told you to. Instead, you are working hard for yourself. This approach is a fundamental distinction, and anyone can feel it. That is, you are signed up to do your work. Thus, the recruiting hundreds of bright engineers and self-motivated engineers, a company can maximize the power of the individual and, therefore, the effectiveness and efficiency of its engineering management. When one person is putting in a 16-hour day ends up being much more effective than two people working 8-hour days together. The individual does not have to hold meetings, reach a consensus, or bring other people up to speed on a project. He just keeps working and working and working. Working 16 hours per day every day for years, you can achieve more than eleven people working together.

E2 must require its reporting engineers to do the impossible on top of the impossible. The executives at SpaceX describe the working atmosphere as a perpetual-motion machine that runs on a weird mix of dissatisfaction and eternal hope. E2 requires that engineering management should not be happy no matter what it is. For example, the December 2010 launch in which SpaceX got the Dragon capsule to orbit the earth and return successfully was one of the company’s outstanding achievements. SpaceX engineers had worked tirelessly for months. The launch took place on December 8, and SpaceX had a Christmas party on December 16. About 90 minutes before the party started, Elon Musk, the founder and CEO of SpaceX, had called his top executives to SpaceX for a meeting. Six of them were decked out in party attire and ready to celebrate the holidays and SpaceX’s historic achievement around Dragon. Musk laid into them for about an hour because the truss structure for a future rocket was running behind schedule. At the same time, the executives’ wives were sitting three cubes over, waiting for the berating to end.

If an engineer understands the engineering methodology and the project’s applicable technology, and if he knows his team plus that everybody can give 200%, then that will result in maximum efficiency and profit for the project. If an engineer does not know or understand the engineering methodology and lacks the ability to interpret the technical provisions of the contract correctly, then it is a fact that he will not be able to produce answers to the everyday project challenges and predicaments, and neither could he provide optimized solutions.

Engineers with E2 must find a way to make the contract’s deliverable requirements, including management plans, engineering reports, and drawings, less expensive and reduce them by 10% to 30% or even 40%. Also, engineers with E2 must be able to assess who adds any ounce of intellectual capital to the project. In today’s competitive environment, engineering projects need result-oriented engineers with this thinking. Engineers with E2 are often frustrated because the staff does not want to dirty their hands and doesn’t want to withstand the harsh conditions of a project for the benefit of the project. Engineers are the cause for doing a project over budget and putting it behind schedule. It is a fact that there are fewer and fewer proactive, motivated, and committed engineers. And guess what? This is mainly the “rule.”

You will always ask your candidate engineers that apply for a position in your department or company whether they are ready to work and do the improbable. This approach is vital because most engineering teams are attached and used to wasteful spending and bureaucracy. Most of the time, nobody is aware of how a salary is produced, and nobody is undertaking the task of keeping an eye on the company or the department’s purse. Overall, I am compassionate about how the budget is spent, and I am convinced that engineering projects can be budgeted and executed at a fraction of the competition. Unfortunately, most of the competition and the clients are smoking their money. Yet, when someone implements a plan towards E2, it is incredible how fast people would adapt when the leader and their team are aware of every engineering and non-engineering aspect of the project. E2 objective should always be to out-maneuver, out-think, and out-execute engineering problems and competition. It is necessary to implement simulations on the project’s schedule critical path to identify potential malfunctions and how those will affect the deliverable’s quality and the budget.

E2 requires leaders who will thrill and amaze people at every organizational structure and the whole company. People should organize the engineering firm or the engineering department around engineers whose impact is the highest. On that note, it must be determined which engineers are having the most significant effect and then set the organization around them. Decide who runs the company not based on function or experience but by performance and passion. Performance should be relatively easy to measure, but desire can be trickier to gauge. It is native to the best leaders, the sort of people elected captain of the team without even volunteering, and it draws others to them like iron filings to a magnet. Debbie Biondolillo, Apple’s former head of human resources, says, “Your title makes you a manager. Your people make you a leader.” When we asked Warren Buffet about what he looks for when acquiring companies, he answered: “A leader who doesn’t need me.” Of course, that does not mean that you should create a star system; in fact, the best management systems are built around an ensemble, more like a dance troupe than a set of coordinated superstars. This approach creates long-term consistency, with a deep bench of high-performance talent ready to lead when the opportunity appears.

A good rule of thumb in staff meetings is that at least 50% of the people at the table should be experts in the company’s products and services and responsible for product development. This approach will help ensure that the leadership team focuses on product or service excellence. Operational components like finance, sales, and legal are critical to a company’s success, but they should not dominate the conversation. You also want to select as your leaders’ people who don’t place their interests above the company’s. Today, we see that a lot in companies with business units or divisions, where the unit’s success, as we noted before, can take precedence over that of the company. Once you identify the people who have the most significant impact, then give them more to do. When you pile more responsibility on your best people, trust that they will keep taking it on or tell you when enough-is-enough. As the old days go: If you want something done, give it to a busy person.

E2 requires the revolution of the engineering processes instead of sticking to a routine. Thus, E2 expects engineers to be innovative. Today, the components are all about information, connectivity, and computing. Would-be inventors have all the world’s information, global reach, and practically infinite computing power. They have open-source software and excellent application programming interfaces that allow them to build quickly on each other’s work. They can use standard protocols and languages. They can access information platforms with data about things ranging from traffic to weather to economic transactions to human genetics to who is socially connected with whom, either on an aggregate or individual basis. So one way to develop technical insights is to use some of these accessible technologies and data and apply them in the industry to solve an existing problem in a new way. Besides these standard technologies, each sector also has its own unique technical and design expertise. So regardless of someone’s business, there is a robust corpus of technical knowledge upon which the industry is based. Who are the geeks in your company? Who are the labs and studios guys working on new exciting stuff? Whatever that stuff is, that’s your technology. Find the geeks, find the property, and that’s where you will find the technical insights you need to drive success. Another potential source of technical insights is to start with a solution to a little problem and look for ways to broaden its scope. This approach is in keeping with a long, fine tradition of Innovation. New technologies tend to come into the world in a very primitive condition, often designed for specific problems. The steam engine was used as a nifty way to pump water out of mines long before it found its calling in powering locomotives.

Bell Labs was so underwhelmed by the commercial potential of the laser when it was invented in the 1960s that it initially put off patenting it. Even the Internet was originally conceived as a way for scientists and academics to share research. As bright as its creators were, they could never have imagined its future function as a place to share pictures and videos, stay in touch with friends, learn anything about anything, or do the other amazing things we use today.

The cost remains extraordinarily high because of one parameter equation, “laziness.” In 1913 Maximilian Ringelmann, a French engineer, studied the performance of horses. He concluded that the power of two animals pulling a coach did not equal twice the power of a single horse. Surprised by this result, he extended his research to humans. He had several men pull a rope and measure the force applied by everyone. On average, if two people were pulling together, each invested just 93% of their strength. When three pulled together, it was 85%, and with eight people, just 49%. Science calls this the “social loafing” effect. It occurs when individual performance is not directly visible; it blends into the group effort. It occurs among rowers but not in relay races because individual contributions are evident here. “Social loafing” is rational behavior: why invest all your energy when half will do – especially when this little shortcut goes unnoticed? Quite simply, “social loafing” is a form of cheating of which we are all guilty, even if it takes place unconsciously, just as it did with Ringelmann’s horses.

When people work together, individual performances decrease. So, what stops us from putting our feet up entirely and letting others do all the hard work? The answer is the consequences of such an act. We would notice zero performance, which brings severe punishments, such as exclusion from the group or vilification. Evolution has led us to develop many fine-tuned senses, including how much idleness we can get away with and how to recognize it in others.

“Social loafing” does not occur solely in physical performance. We slack off mentally, too. For example, the larger the team, the weaker our participation in company meetings. However, our performance plateaus once a certain number of participants are involved. Whether the group consists of 20 or 100 people is not essential – maximum inertia was achieved in the 1970s. Japanese flooded global markets with their products when their factories were organized into teams. We copied this model with mixed success. What worked well in Japan could not be replicated by the Americans and Europeans. In the West, teams function better if and only if they are small and consist of diverse, specialized people. This approach makes sense because we can trace individual performances to each specialist within such groups.

“Social loafing” has exciting implications. In groups, we tend to hold back not only in terms of participation but also in accountability. Nobody wants to take the rap for the misdeeds or poor decisions of the whole group. Often, we hide behind team decisions. The technical term for this is “diffusion of responsibility.”

For the same reason, teams tend to take more enormous risks than their members would take on their own. In conclusion, people behave differently in groups than alone (otherwise, there would be no groups). We can mitigate the disadvantages of groups by making individual performances as visible as possible.

E2 and the “yes” attitude. The attitude of the “No” answer in the workplace is like death to engineers. No signals that the company is following a corporate culture that features a lack of flexibility. While the “Yes” attitude keeps things happening and growing. Saying “Yes” leads to new experiences, and new experiences will lead you to knowledge and wisdom. An attitude of “Yes” is how you will be able to go forward in uncertain times. Unfortunately, in today’s big engineering projects, there is spawn chaos, which most engineering managers try to control by creating most processes. While some of these processes may be required to help the project and the company, they should be postponed as long as possible. Set the bar for that new process or approval gate. Make sure that there are very compelling business reasons for it to be created. E2 platform engineers are required to be thinkers, not yessers.

Getting everyone to say yes in a meeting doesn’t mean you have an agreement; it means you have a bunch of yessers. Many leaders strive for “consensus-driven” decisions but fundamentally misunderstand the meaning of consensus. Consensus is not about getting everyone to agree. Instead, it is about coming to the best idea for the company and/or the project and rallying around it. Reaching this best idea requires conflict. People need to disagree and debate their points in an open environment because you won’t get buy-in until all the choices are discussed openly. So to achieve true consensus, you need dissent. E2 engineers do not state their position at the outset of the process. The job is to make sure that everyone’s voice is heard, regardless of their functional role, which is harder to achieve when the top dog puts a stake in the ground. “If everyone is thinking alike, then someone is not thinking,” said General Patton famously. E2 engineers, particularly at the highest levels of leadership, should and usually consider themselves business owners rather than leaders of their specific field. Therefore, they should have opinions and valuable insights, even about decisions that fall outside their realm. E2 engineers encourage this approach since it helps build a stronger bond among the team and more robust support for the ultimate decision.

A few years back, the former head of YouTube, Salar Kamangar, had his “attitude of Yes” moment. It came to his weekly staff meeting, at which the testing of a new feature (a high-definition playback) was being discussed. The testing was going well. So well, Salar asked if there was any good reason we could not launch the feature immediately. “Well,” someone replied, “The schedule says it’s not supposed to be released for several more weeks, so we can test it further and make sure it works.” “Right,” Salar replied, “but besides the schedule, is there any good reason we can’t lunch it now?” No one could think of one, and high-definition YouTube launched the next day. Nothing blew up, nothing broke, and millions of happy YouTube users benefited weeks early from one man’s commitment to saying “Yes.”

E2 requires mutual loyalty and dedication from its leaders and employees. Hire people who need to believe in you and in your idea enough to be willing to make the same sacrifices. This approach requires commitment, tenacity, and, most of all, single madness. In ancient times the generals were heading their troops into combat by shooting “follow me.” Anyone aspiring to lead intelligent and dedicated engineers must adopt this attitude.

Urs Holzle, the engineering executive who led the creation of Google’s data center infrastructure, picked up small trash in the hallway as he walked through the office. This approach is a common refrain in Silicon Valley, with the CEO picking up the stack of newspapers outside the front door and the founder wiping the counters. With these actions, the leaders demonstrate their egalitarian natures. We’re all in this together, and none of us are above the mundane tasks that must be completed. Mostly, though, they do it because they care so much about the company. Leadership requires passion. If you don’t have it, then get out now.

E2 requires self-awareness and engineering dedication. Teams in E2 must have self-awareness and commitment regarding their technical deliverables. Specifically, the engineers should make clear that their deliverables are: (a) fit for purpose design, (b) safe, and (c) in compliance with the technical provisions of the contract. When Toyota invented its famous “Kanban System” of “just-in-time production”, one of its quality control rules was that any employee on the assembly line could pull the cord to stop production if he noticed a quality problem. The same philosophy lies behind Google’s mantra, “Don’t be evil.” Specifically, every Google engineer is forced to assess the proposed feature and determine if it is consistent with the company’s values. This is the ultimate benefit of a well-established and well-understood engineering culture. It serves as the foundation for everything you and your company do. Because it is the rails, it is the safeguard against something going off the rails. After all, the best cultures are aspirational.

E2 requires planning. E2 must make sure that its planning has all the answers. Engineering planning must be a clear-cut blueprint and then must be based on a fundamental set of principles. E2 must give those foundational elements to the engineers, and then they would figure out the rest. These principles are bet on technical insights that help solve big technical problems novelly, optimize for scale, not revenue, and let great products grow the engineering perspective for everyone. For example, in the mid-1990s, when the Google founders Larry and Sergey began to research the Ph.D. thesis project that would become Google, the leading search engines ranked their results based on a website’s content. For example, if you typed in “university,” you were just as likely to get a link to a bookstore or bike shop’s website as to an actual university. In fact, during a visit to one of those search companies, Larry complained about the poor results he got when he used the “university” query within their product. The fault was his, we told him. He should have been more precise with his questioning. So, Larry and Sergey discovered a better way. They figured out that they could determine the quality of a web page – how relevant its content would be in answering the user’s query – by figuring out which other pages linked to it. Find a page that many other pages point to, and you have probably found a page with higher-quality content. There are a lot of different factors that made Google Search so much better than the competition when it launched. Still, the heart of the product’s advantage consisted of this single technical insight about using the web’s link structure as a roadmap to the best answer. Since then, most of Google’s successful products have been based on solid technical insights, while most less successful ones lack them.

E2 requires technical insights. E2 involves the application of technical understanding upon which we will build those new features, products, or platforms. Specialized knowledge is a new way of applying technology or design that either drives down the cost or increases the functions and usability of the product by a significant factor. Developing technical insight is hard, which is perhaps why most companies don’t make it a strategy foundation. Instead, they would instead follow the conventional MBA approach of figuring out what they are best at (their competitive advantage, per Michael Porter, a professor at Harvard Business School) and then leveraging their technical insight to expand into adjacent markets. Overall, the best products have succeeded based on technical factors, not business ones, whereas the less stellar ones lacked technical distinction. Don’t measure success by the number of deliverables or users. Through this approach, we trick ourselves into believing that the products are successful. The flat-lining products were always the ones that lacked technical insights. We are entering a new period of combinatorial Innovation. This approach happens when “there is excellent availability of different parts that can be combined or recombined to create new inventions. For example, in the 1800s, the standardization of the design of mechanical devices such as gears, pulleys, chains, and cams led to a manufacturing boom. In the 1900s, the gasoline engine led to innovations in automobiles, motorcycles, and airplanes. By the 1950s, it was the integrated circuit proliferating in numerous applications. Developing complementary components in each of these cases led to a wave of inventions.

According to Hal Varian, the current human experience is a new epoch of combinatorial Innovation. This approach occurs when there is excellent availability of different parts that can be combined or recombined to create new inventions. Today the components are all about information, connectivity, and computing. Would-be inventors have all the world’s information, global reach, and practically infinite computing power. They have open-source software and abundant APIs (Application Programming Interfaces, which enable software applications to interact with other systems) that allow them to build quickly on each other’s work. They can use standard protocols and languages. They can access information platforms with data about things ranging from traffic to weather to economic transactions to human genetics to who is socially connected with whom, either on an aggregate or individual basis. Thus, one way to develop technical insights is to use some of these accessible technologies and data and apply them in the industry to solve an existing problem in a new way.

E2 hiring platform for talent engineers should be based on the following criteria. Criterion #1: “Leadership,” E2 engineers must demonstrate how they have flexed different muscles in various situations to mobilize their team. This approach can include asserting a leadership role at work or with an organization or even helping a team succeed when they were not officially appointed as the leader. Criterion #2: “Role Related Knowledge” E2 engineers must have a variety of strengths and passions, not just isolated skill sets. Also, E2 engineers must have the experience and background to set them up for success in their roles. E2 engineers should be checked out on technical areas of expertise and coding skills. Criterion #3: E2 engineers must be able to answer role-related questions that provide insight into how they solve problems. Criterion #4: E2 engineers must be distinguished for their uniqueness. Additionally, signs around their comfort with ambiguity, bias to action, and collaborative nature must be checked. Based on the above five criteria, the E2 hiring “Dos and Don’ts” are the following:

• Hire engineers who are more intelligent and more knowledgeable than you are. Don’t hire engineers you can’t learn from or be challenged by.

• Hire engineers who will get things done. Don’t hire engineers who just think about problems.

• Hire engineers who will add value to the product and the company’s culture. Don’t hire engineers who won’t contribute well to both.

• Hire engineers who are enthusiastic, self-motivated, and passionate. Don’t hire engineers who just want a job.

• Hire engineers who inspire and work well with others. Don’t hire engineers who prefer to work alone.

• Hire engineers who will grow with your team and with the company. Don’t hire engineers with narrow skill sets or interests.

• Hire engineers who are well rounded, with unique interests and talents. Don’t hire engineers who only live to work.

• Hire engineers who are ethical and who communicate openly. Don’t hire engineers who are political or manipulative.

• Hire only when you’ve found a great candidate. Don’t settle for anything less.

E2 must always decide with data. One of the most transformative developments in the E2 today is the ability to quantify almost any aspect of engineering issues. Decisions were based on subjective engineering solutions and anecdotal evidence. Now, they rely primarily on data. Companies like Google aggregate anonymous signals from computers and mobile phones to provide accurate traffic data in real-time. Therefore, most conference rooms at Google have two projectors. One is for video conferencing with other offices or projecting meeting notes. The other is for data. When discussing options and opinions, Google engineers start the meetings with data. They don’t seek to convince by saying, “I think.” They convince by saying, “Let me show you.” A bias toward data is a great way to kill the death-by-Power Point syndrome. E2 engineers presenting a point of view in a meeting should not need the crutch of slides to present that argument, only to support it. We should not use slides to run a meeting or argue a point. They should just contain data so that everyone has the same facts. You cannot fix the data with fancy slides if the data is wrong or irrelevant. Thus, visual reasoning usually works more effectively when relevant information is shown side by side. Often, the more intense the detail is, the greater the clarity and understanding.

The data is best understood by those closest to the issue, which is often not management. As an E2 leader, it is best not to get lost in detail you don’t understand but rather trust the intelligent people who work for you to understand them. When making financial decisions, for example, don’t worry about the ABCs of the MBAs’ and CPAs’ EBITDA, ADRs, and RPM; focus on what matters, usually cash and revenue. I frequently say that revenue solves all known problems. This view also applies to technical and product decisions for the E2 engineers and their executive management.

If there is too much data or the information is inconclusive. People can debate for hours, a time sink that often ends in mediocre compromise and always incurs a hefty opportunity cost since they’re always better things for E2 engineers to be doing than reshaping a decision for the umpteenth time. There is a point at which more analysis won’t lead to a better decision. This perspective is the essential duty of the E2 decision maker: Set a deadline, run the process, and then enforce the deadline. It’s like the kids on the playground at recess; they will play forever, but when the bell rings, they know they have to wrap it up and head back to class. E2 engineers are better behaved and less prone to hogging the monkey bars. Thus, the decision-maker gets to decide how long recess lasts. Then he rings the bell.

The E2 platform must implement an effective communication list of guidelines. I believe that today there is an over-communication that is done wrong and leads to a careless proliferation of useless information, an avalanche of drivel piling into already overwhelmed boxes. Here are a few of E2 basic guidelines for overcoming destructive communication. 

Guideline #1: Communication should reinforce core themes to the right engineers. To get this right, you first need to know the core themes. For example, at Google, their themes include putting users first, thinking big, and not being afraid to fail. Also, they are technology optimists. By the way, if you repeat something twenty times and engineers don’t get it, the problem is with the theme, not the communication. 

Guideline #2: Communication should be adequate. To get this right, you first need to have something fresh to say. Sometimes the presentation of the idea has to be varied to grab attention. 

Guideline #3: Communication should be interesting, fun, and inspirational. People and E2 engineers like it when a leader or individuals from the same organization take off the blinders and talk about a wider variety of things.

Guideline # 4: The communication should be authentic. If it has your name, it should have your thoughts in it. Effective communication cannot be 100% outsourced. Yes, you can have people help you make the words pretty, but the opinions, ideas, and experiences need to be yours. The more authentic, the better. 

Guideline #5: The communication should go to the right people. The problem with email is that it’s too easy to add recipients. However, good communication goes only to the people who will find it useful. 

Guideline #6: Tell the truth, be humble, and bank goodwill for a rainy day. Setting a constant tone of truth and humility creates a store of friendship and loyalty among the team of E2 engineers. Then, when you’ve screwed up, communicate that story with truth and humility. You may draw down that balance of goodwill, but not completely. 

Guideline #7: Apply email wisdom.

Communication in the Internet Century usually means using email, and email, despite being remarkably useful and powerful, often inspires momentous dread in otherwise optimistic, happy humans. Here are my rules for mitigating that sense of foreboding: (a) Respond quickly. Being responsive sets up a positive communications feedback loop. (b) When writing an email, every word matters and useless prose doesn’t. Be crisp in your delivery. (c) Clean out your inbox constantly. (d) Handle email in LIFO order (Last in, First Out). (e) Don’t yell. If you need to yell, do it in person. It is far too easy to do it electronically. (f) Make it easy to follow up on requests. When you send a note to someone with an action item you want to track, copy yourself, then label the note “Follow up.” That makes it easy to find and follow up on the things that haven’t been done; just resend the original note with a new intro asking, “Is this done?”

E2 platform requires innovation context. To me, Innovation entails both production and implementation. For example, Google’s project to create cars that can drive themselves fits my definition. It is new, surprising, and radically useful. Before there can be Innovation, there needs to be the proper context for Innovation. This approach is usually found in markets proliferating and full of competition (many companies are working on automated cars; most are car companies). Don’t look for a space and then be lonely; it is much better to use an innovative approach to become a player in an area that is or will be enormous. This approach may seem counterintuitive since many entrepreneurs dream of entering “greenfield” markets that are brand new and have no competition. But usually, there’s a reason the market is empty. It is not big enough to sustain a growing venture. It still may be a good business opportunity – someone must make money off all those niche products we see in the Sky-Mall catalog – but if you want to create an environment of Innovation, it’s better to look for big markets with tremendous growth potential. Remember, Google was late to the search-engine party, not early.